Develop Reference

Convert Spritekit Game to Android?

Are there any new options for converting a spritekit game to android? It seems the only options are to recode everything in Java or to use Cocos2D, LibGDX, etc.

Unfortunately ... no :{
And the cross-platform SpriteBuilder with the Apportable service that let you convert a Swift Cocos project to Android is no longer available (they got bought out by Google I believe).
SpriteBuilder is still available on GitHub but it's not active afaik and is abandoned.
So... what to do?
I would focus on iOS... you can make your game "cross platform" by converting to macOS and tvOS... This is where all of the money is in the market... Apple products...
If your goal however is cross platform, then you can look at Xamarin.forms alongside CocosSharp which will give you write once run everywhere games in C#
You also have regular Xamarin available to write gameplay code in C#, and share it across Android and SpriteKit wrappers written in C# as well.
Another thing to look at is Silver which has Swift wrappers for Android.. thus letting you port Gameplay code almost directly...
In all scenarios you will have to find another game engine for whatever Android solution you use..
IMO, developing with Swift for Apple is much easier and more fun than anything I've ever done with Android dev, even though I prefer Android devices (go figure), and since the revenue is higher it is sort of a no-brainer for starting up.

There are no easy options for supporting Android with a SpriteKit game, but with a little bit of work and not too much difficulty you can recode your game to use Cocos2d-x. I just completed such a project for my game. It took me about four months working half time. I've posted some tips here: http://doffen.org/porting-spritekit-to-cocos2d-x.

I would suggest to have a look here: http://processing.org/
and here : http://www.ricardmarxer.com/fisica/
Fisica is a wrapper of jBox2D for Processing and is quite easy to use. There are a few tweaks for android but nothing too hard.
I did it in the opposite direction (converting my fisica-based game to SpriteKit) and it was quite easy to create regex replacement to easily migrate to swift syntax.

Porting a game developed in Qt (for KDE) to Android

I have game (of cards based on Contract Bridge) written in Qt (QML) for KDE, now I'm supposed to port the entire game to Android (with Android apapted UI of course). At first I considered to use Necessitas (a Qt port for Android) but found that it is still under development and is currently in 3rd Alpha. I'm new to Android development (as well as game development), while I have experience working in Java, C++ and web technologies like HTML5, JavaScript.
Hence based on my skills, I considered using MoSync. But I'm not sure if I'll be able to use any existing modules of game already developed in Qt (while in MoSync its possible to invoke C++ code from JavaScript and vice-versa), and since I didn't worked on the Qt version of the game, I'll first have to refer to that code and then I'll be working on Android version of the same. So I need suggestion that from where should I start. Also, I have 1.5 months of duration to complete the project (without any working hour constraints), so also suggest me if its a good idea to work from scratch using Android APIs.
Please let me know if I need to elaborate the question even further.
Thanks.

I recommend taking a look at V-Play (v-play.net). It's a cross platform game engine based on Qt/QML .
If your game is already written in QML, you have the least porting effort because you can use almost all of your existing code, and use V-Play QML game components for handling multiple display resolutions & aspect ratios, animations, particles, physics, multi-touch, gestures, path finding and more (API reference).
You can also take a look at Benefits to find out if V-Play satisfies your demands.

Qt is more cross-platform than ever now. instead of porting, just modify it a little and continue with Qt, then compile for iOS, Android, etc.

How well does Unity 3d work for both Android and iPhone?

I'm not sure if this is the best place to ask this question so if it isn't please let me know and I will move it. I am looking to create a game for both Android and iPhone platform. I know Unity is a great game engine and my question is how well does it work for creating one code base to build for both Android and iPhone platforms? Time is a constraint on this project so I am very interested in how smoothly the process usually is when trying to build both applications and how much custom code must be written for each specific application. Any insite that people have on this topic would be much appreciated thanks.

Unity, as implied by it's very name, is designed explicitly to facilitate such multi-platform development in little time. You can for example define for each platform what the max size of each texture is, and it will automatically resize them for you when you build for that target platform - the build process really simple too. Since both your platforms are touch devices, it should be easy to have just one code base working seamlessly for both platforms (and more if needed), with very few custom code for each platform.
Unity has a no-questions-asked 30 day trial of the Android and (I think) iOS versions - I encourage you to try them and see for yourself how little time it will take you to have a proof of concept build for both platforms.

MonoDroid VS Java in android development?

I know C# rather well and just love Visual Studio as IDE. :) Yet now I want to start developing for android...
I found out about MonoDroid and wanted to ask if it has any downsides to it that would make Java more preferable, or should I uninstall Eclipse and dive straight into MonoDroid?
If I understand right, MonoDroid deploys/compiles native android applications and does not need any additional .net-like framework or anything?
Are there any significant limitations to what I can do with MonoDroid? For example, having the app run in the background or using some external .net libraries for image editing, etc. ?

I've been worrying about the same thing - productivity in C# instead of playing with an unfamiliar language, vs developing how the OS developers intended it to be.
Its easy to list pros vs cons -
pros (of monodroid, for C# developers)
familiar dev environment, can develop using Visual Studio
C# instead of Java
Reusable code assets - you can use a lot of code in your iphone project or Windows phone 7 project using monotouch and the WP7 SDK.
cons -
debugging could be difficult, due to lack of api documentation from Google. Will have to depend solely on monodroid documentation.
there could be a lag when it comes to latest cutting edge features - safe to assume that the monodroid team will require some time to wrap around the latest android features every time there is a new OS release
availability of libraries - I am not sure how you can use the open source libraries that would have evolved around the android platform, that could cut down on development time

Much of the documentation available is in Java: so if you run into difficulties with phone behavior when using MonoDroid you won't really find that much help or debugging information so you may want to stick with Eclipse.

There's a lot more than just a set of wrappers running under davlick, truth to be told, there is much more of a horizontal relationship between MonoDroid and Android;
When did using the same language as the OS developers become a big issue? There's lots of C++ programmers wondering how to use BSD or SVR5 and many C programmers who want to know what the heck to do on Windows++...

If you will write in c# anyway you will be have to wrap it into a Java code, so what's the point ? Also you may head with a very difficult issues while trying to understand the APIs who written for Java programming...

Here are some points that you can mull over:
Android applications are predominately written with Java. The Android SDK itself is natively written in Java.
Working in Mono may not provide all the functionality available in the Java SDK.
If you are a C# Developer you wont be able to find, in Java, some of the (cool) features available in C# (like Property Delegates etc).
Code written in .NET can be re-used for other environments - this may save a lot time that would have been spent learning a new language/environment (like Objective C), and coding in it.
.NET extends the Android development stack with it's existing libraries and API's.
I think both are good for certain reason. It will be very hard to say which one is preferable for Android development - in the end that is up to you too decide.

Also note that any release build using monodroid adds an additional 4mb to the apk filesize and increases app startup time with a few seconds.
For simple apps this can mean a 500-800% increase in filesize - whic is pretty bad in my book.

Titanium compatibility with Android

Will Titanium work properly on all android sdk versions (1.5, 1.6, 2.0, 2.1, 2.2).....

Based on the research I've done, yes, I believe so. I'd recommend trying it out.

Yes it is.
But be warned that while Titanium has its strengths, it also has its weaknesses (ie; memory).
If you're working on a project for a client or are just starting your journey into mobile development, I would recommend learning how to code a native application. At least that gives you some options if you run into troubles. I've been burned a couple of times.

Titanium works with all android SDKs .You just have to make some changes to make it work with all SDKs. Titanium works with sdk 2.1 and below without any changes. But in order to make it work with 2.2 and above you have to add a symbolic link of adb file which is in
platform-tools(source) folder to tools(target).

Occasionally the platform-level support for a particular feature is different between the iOS and Android. For instance, the underlying audio support is significantly better on iOS; many features are simply missing on Android (we eventually patched them ourselves).
In addition, the way that the underlying platform's primitives are wrapped differs, so that code that is correct Javascript will result in incorrect Java on Android. An example we came across was related to the treatment of null and undefined when used with the Ti.App.Properties.setXXX functions. This issues are becoming fewer and farther between, as mentioned, but there are still issues not just related to UI.
I suggest you make a point of continuously developing and testing on both platforms; you'll find incompatibilities (mostly related to leaky abstractions) and their workarounds more easily that way.

Well it works great for the cross platform Execution.
The Only problem is that when user want to compare the iphone version & Android Version by developing same code.
iphone is excellent as per its gesture supports & fine UI works.While Android is still improving the terms.
So you should firstly check your terms and requirement then Go a head with Titanium. OtherWise
Appcelerator consistently working around all the native support as well as common features.
you need to find the possibilities in proposal for the Framework.it will be great approach & future perception as well.