Hi Guys, it’s Chris. I haven’t written a blog post in ages. They’ve kept me locked in the basement like Milton Waddams, unwilling to let me out to see daylight until I finished X-Plane 10 Mobile. And they stole my #$%#^ stapler!
We recently released X-Plane 10 Mobile for iPhone/iPad and while the Apple users were ecstatic, some Android users were puzzled while others were frustrated.
“Will there be an android version?”
“When’s it coming to Android?”
“Where’s the Android version? 60% of all smartphones run on Android but I guess that Apple-Fan-Boys are more important in your company”
“Why do you guys constantly focus on iPhone first when most users are on Android?”
Before I get into the real point of the blog post, allow me to answer some of those questions. YES we are planning on shipping X-Plane 10 Mobile for Android. YES we have already begun development. We do not have a release date. We do not have any hints. The only thing that I can say, is that we want it out just as soon as you do. NO we do not view Android as a lesser/inferior platform…We value Android customers just as much as we value our iOS customers. A customer is a customer. I think we’ve demonstrated by supporting Windows, Mac and Linux all these years that we’re not trying to play favorites. We want everyone to be able to enjoy our products. BUT, that doesn’t mean that the costs of development and the speed and efficiency of development is equal on all platforms.
Historically, we’ve always developed for iOS first and then Android second. I’d like to be open an honest about our reasons and hope that even if you disagree with them, you’ll at least understand why we have historically developed for Apple first. I will warn you, everything I have to say is completely my opinion, my impression, my feeling based on my experiences. I’m going to sound a lot like an Apple “fanboy”. I will admit, I do have a high level of respect for Apple’s commitment to polish and detail, but I also own a dozen android devices and respect them for their cutting edge features, their openness and their friendliness to customization.
At the end of the day however, I’m paid to be efficient and thorough and my thoughts below explain why that means Apple has historically come first.
I will also warn you…I don’t want this blog post to turn into a flame war between Apple and Android users. We’re talking about phones here people, not religion. At the end of the day, they’re just small piles of plastic and silicon that let us surf the web, make phone calls and play games.
We Can’t Develop Apple and Android In Parallel
Sure, we do this on desktop by releasing Windows, Mac and Linux versions in unison 100% of the time. Developing for desktop is pretty different than developing for mobile. We use very few 3rd party frameworks on desktop and it’s an open environment. On a mobile phone, it’s a very closed environment. What this means is that developing Apple and Android in parallel requires a lot more effort than developing for Windows and Mac in parallel.
Can it be done? Absolutely! Plenty of companies are doing it. But they also have large teams with large expenses. We’re still a pretty small group of individuals and we like it that way. The tradeoff however is that we can only focus on one platform at a time.
One alternative that we could consider is delaying shipment of an Apple product until the Android version is done as well. That’s a loss for everyone. Apple customers lose out on having the latest software and Android customers may lose because…we don’t have the revenue coming in to support the Android development costs. That’s right…Apple sales get reinvested into the company to fund Android development!
As Ben mentioned earlier…Apple and Android mobile sales fund desktop development…and desktop development funds mobile development! This is a very important fact to remember. I’ll admit, we laugh and roll our eyes when desktop users complain about the company working on mobile products, and mobile users complain about the company working on desktop products….and android users complaining about us working on apple products and vice versa.
The company has found equilibrium creating both desktop and mobile products. There’s adequate revenue to fund adequate staffing to continue to develop both.
We Develop On Mac Hardware
This is no secret. It’s been this way since the company started. We just find Apple products allow us to be more productive and don’t get in our way.
Historically, Apple’s Mobile Platform Has Been More Mature
Apple had both a technological advantage as well as a time advantage over Android when they began.
Apple already had an Operating System, supporting frameworks and a development environment to leverage. Making mobile versions of those things required them to port existing, time-tested code to a new platform. From a stability standpoint, Apple had the advantage in that they already had the code, the engineers and the process in place to do this.
On the other hand, Google had to start from scratch. They had to put together a new team to create a new operating system to run new frameworks…and they had to create a set of tools for developers to use.
In addition to all of the technological advantages Apple had, they also had a head-start of well over a year. We were already selling X-Plane V9 for mobile before Android was even announced publicly.
That meant we were already established and familiar with the iOS platform as developers.
When I began the Android port for X-Plane V9, I had to pretty quickly put it down…and wait. Android at the time only supported Java apps. X-Plane is NOT a Java app. 99% of it is written in C/C++ and Android had absolutely no support at the time…and so we waited….and waited….and waited.
Finally, many months later, Android added their NDK which allowed us to have C/C++ support. But it was completely minimal. None of the standard libraries that we were used to using were available. This meant a lot of effort on our part to get anything done. If you’re not a developer, a reasonable metaphor might be a carpenter that’s trying to build a house, but he first has to build his own hammer, nails, square and saw because the tools he’s used to using don’t exist on this job.
Finally it came time to release V9 for Android. For iPhone/iPad, we uploaded our 400+mb app to their store and we were done. On Android however, the store had a limit of 25MB. So that meant we had to buy servers and write code to download the resources from a farm of servers. Again, this added more time and more complexity.
Apple Has Fewer Devices
For this latest release of X-Plane Mobile, we support iPhone 4S/5/5S/6/6+ as well as iPad 2/3/4/Air/Air2/Mini/Mini2 and iPod Touch 5. That’s 13 devices to my recollection. But it’s even simpler than that…because they all have the same GPU manufacturer, they all support the same PVR texture compression, and they all pretty much just work interchangeably from a development standpoint. The only major differences between them are the processor speeds and the screen resolutions. We can literally test on every single device and be sure that the app runs the way we expect it to.
As of the time of this writing, our X-Plane V9 is running on 7,072 devices. You read that right….SEVEN…..THOUSAND…..DIFFERENT……DEVICES. Each device has a different combination of CPU, GPU, screen size, screen density and drivers. We cannot possibly test them all. Admittedly, many of them “just work” and there are of course only a handful of CPU and GPU manufacturers to worry about…but at the very least, it means at least three different texture compression formats. PVR is proprietary and unless the mobile device has a PowerVR chipset, they’re not going to get PVR. So we have to support various formats. That requires three different versions of our app to be created and tested and distributed. That requires three different resource packages to be created and tested.
There’s just no way to have the same level of stability as we can have with the iPhone/iPad platform.
Apple Has Higher OS Upgrade Adoption
Without carriers and other manufacturers getting in the way, Apple can release a new OS with features and bug fixes, and we can be sure that they exist on the majority of the devices that we care about in no time. This means that if there’s a driver issue that needs fixing, it will make it out to the masses and eventually the problem is gone.
Android’s fragmentation has really hurt them in this area. We encountered several devices over the years that violated some OpenGL spec. We worked with the manufacturer to isolate the issue. They release a patch to fix the issue…and most users never had a way to get the patch because their phone carrier dropped support for that phone model.
Now the user’s stuck with an App that they paid for that doesn’t work and there’s nothing that we can do about it.
We like Apple’s Developer Tools Better
As I mentioned earlier, Apple’s developer IDE has been around for ages. We have access to various performance analyzers and can now even analyze an entire OpenGL frame, one draw call at a time. This means we can really tune the crap out of the app before we make it public. In addition, all of the tools come in a single package that just works out of the box. Apple has also always had a simulator that’s hardware accelerated. This means for a lot of things, i don’t need a device plugged into the computer to debug something.
Android’s solution was for less “out of the box” in that they were using various open-source pieces that all had to be installed and fit together just right. Android had an emulator that was not hardware accelerated. It took longer just to boot than it took me to find a phone in my house, get it, plug it in and push an app to it.
Honestly, I think both sets of IDEs are sorely lagging behind features that Microsoft’s Visual Studio has had since 2000, but I digress.
TL;DR
We develop for Apple first because it’s easier and faster for us. It allows us to get the product out the door, running as efficiently and as reliably as possible. When we port the app for Android development, we can be sure that most bugs that come up are specific to Android and are therefore much easier to resolve in a timely fashion.
We are not playing favorites. We have no personal issues with Android and have no personal ties to Apple. The day that Android becomes the faster and easier platform to develop for, it will be the one that we develop for first. It’s just a business decision!
In the meantime, Android users should remember that the way things are currently being done means that they sometimes have to wait longer for new updates, but the updates that they receive will likely be more stable as they’ve been tested harder.
I will also note that we are closing the time gap between iPhone and Android releases. In the past, we were over a year behind on the Android release…because Android didn’t exist. 🙂 Now that it’s becoming more established, the gap should be shrinking more and more.
When I was very young, it was hard to watch my younger brother get presents on his birthday. I was jealous! Why should he get all of the attention? I was here first!
When I was just a little bit older, I realized that my brother’s birthday was actually a pretty good day for me too. You see, my brother and I had one big pile of toys, so whatever my brother received as a gift would be available to me too; all I had to do was be patient and not snatch his toys for a few days.
The new announcement for X-Plane 10 Mobile is clearly trying to whip up a little bit of sibling rivalry: “X-Plane 10 Mobile will make our desktop users jealous.” Besides being a chance to plug X-Plane 10 Global to mobile users, it is also a reference to the inevitable emails we did get (for X-Plane 9 vs X-Plane 9 Mobile) and will get from desktop users who are jealous of the development resources we spend on the mobile product.
Here are a few notes on X-Plane desktop and mobile and the relationship of the two products.
First, X-Plane 9 Mobile funded the development of X-Plane 10 Global. Had we not shipped X-Plane 9 Mobile, there would not be an X-Plane 10 Global, and I probably would not still be working at Laminar Research. So even if you ignore leverage and synergies between the code and you consider mobile products to be a distraction from the true purpose of X-Plane (desktop flight simulation), you can’t ignore that mobile is part of our business, perhaps a part that should not be discarded.
Second, we have been moving to a “two fronts” strategy where we can actively develop both products at the same time, and we have hired more developers so that we can do so. X-Plane 9 waited while X-Plane 9 Mobile was developed, and then the mobile product was more or less frozen for years while we worked on X-Plane 10 desktop.
The level of ping-pong hasn’t been as bad for X-Plane 10 mobile. We shipped 64-bit support, deployed the airport gateway, ported to Steam and shipped a brand new GPS while developing X-Plane 10 Mobile.* This has not been easy, but I think it indicates that we’re making progress towards “two fronts”. Both desktop and mobile suffer if they have to sit in the penalty box for years on end while the other is developed.
Finally, mobile devices are now powerful enough that we can share code and art assets between the two code bases. A few examples:
- Our minimum OpenGL requirements for the mobile product is OpenGL ES 2.0; our minimum desktop OpenGL version is OpenGL 2.0. And the capabilities required by both (render-to-texture via VBOs, vertex and fragment shaders) really are as similar as they sound.
- I have an iPhone 6 and a 2008 8-core Mac Pro. I ran the particle system performance test code on both and they run at almost the same speed. Obviously the Mac Pro is 6 years old and the iPhone 6 is a top-end phone. But there is no gap. This means that an older but supported desktop device will have similar characteristics to the top end of mobile devices. It’s just one big spectrum of computers now.
A lot of code was moved from desktop to mobile for X-Plane 10 mobile. But code was also developed for X-Plane 10 mobile with the intention of moving it back to the desktop version of X-Plane.
My take-away point: if you use our desktop product, you don’t need to actually be jealous of new toys in X-Plane 10 Mobile. Those toys are meant to be your toys too.
* One thing to note about this list: our ability to do more than one thing at once is mostly limited by who will do the work. Different developers and artists in the company have different skill sets; our developers are not interchangeable robots. Well, one of our developers is a robot, but I’m not going to name names.
On the menu this morning: first a whiny rant, then a nerdy one.
Someone pointed me at this post. Before I go into my geeky diatribe about leveraging code, a quick note: it is true that at this point Austin is working heavily on the iPhone – probably more on the iPhone than the desktop. It is also true (but not mentioned) that Laminar is investing more man power into X-Plane for the desktop now than it ever has in the past. (With the iPhone we’ve grown our workload with a second “front” for products, but we’ve increased staffing a little bit too.)
It is also true that X-Plane 9 free updates have been less frequent. This doesn’t mean there’s less code going into them – it just means that we’re doing 4-5 months of coding and 3 months of beta instead of 2 months of codindg and 1 month of beta. I’m not sure if this is better or why it is happening (each release has to be individually planned for the circumstances) but one observation:
Given how many video cards and drivers are out there and how they react differently to the X-Plane code, I wouldn’t want a beta process less than 2-3 months, because I want to know that it’s had time to run on a wide variety of hardware. If our beta has to be at least 2-3 months, then a 3-month release cycle would have us in beta all the time!
My whiny rant (the short version) is this: Laminar Research isn’t in a position (as a company selling a product) to post all of the details of how our business operates internally. So posts that say “Laminar should do X” (where X is a business decision) drive me a bit nuts, because I can’t post a reasonable reply.
Now here’s my real point: development for the desktop and the iPhone are not a zero sum game. Clearly we leveraged the desktop sim to create the iPhone app. But it goes both ways; work on the iPhone also benefits the desktop.
Here is one example: when beta 8 comes out, Plane-Maker’s “export to object” will a much more complete OBJ, in OBJ8 format, with animations already in place for things like wing controls surfaces!
That’s a feature that people have been asking about for a while – both to make CSL objects* and as a way to save time when moving from a Plane-Maker drawn plane toa custom one. (You would first export an animated OBJ8, then start adding details in a 3-d modeling program. With beta 8, you won’t have to rebuild your control surfaces from scratch.)
But…it’s also a feature that is critical to the iPhone! The iPhone version of X-Plane uses animated OBJ8 files as well; this feature helped us internally to prepare planes for the iPhone version, but it’s also a requested feature from our authors.
So my response to those who say that the iPhone has taken away from X-Plane development is that it is not true – not only because we are developing more heavily for the desktop, but because sometimes iPhone development is for the desktop.
* I do not remember whether the current compiled versions of libXplaneMP use OBJ7 or OBJ8 objects. Since libXplaneMP uses the OBJ code from XPTools, it should be (relatively) straight forward to update libXplaneMP and the clients that use it to use OBJ8 directly. In the meantime, you can use ObjConverter to convert an exported OBJ8 back to OBJ7 for CSL use.
