One of the coolest thing about working with technology is that technology is constantly changing and evolving. A good case in point is to reach into your pocket and pull out the SmartPhone that you likely have there. Think back to ten years ago or more and recall the cellphone you had back then – it probably made phone call, might have had the ability to take very basic photos and possibly had a text messaging feature. If you were really lucky, it might have had a few decidedly basic apps, but nothing to call home about.
Fast forward to today. That SmartPhone is a full featured computer. Yeah, it can make phone calls, but what makes that Android Phone, iPhone or Windows Phone cool is that you can run a multitude of applications on it. The demand for new and unique apps is strong no matter the device, yet there are some distinct differences in how these apps are created for each device, so we will take a look at the development environments for iOS and Android devices.
Before we go much further – we are not beholden to one platform or the other. Indeed, Unbounded Solutions develops apps for Android and iOS, as well as for Windows Phone. We’re also kicking the tires of Google Glass. Our point being is that we’re not about to slam one platform just to sing the praises of the others. We focus on developing mobile apps for businesses and organizations. Period.
That actually gives us a good perspective to compare the development environment of iOS to Android.
IOs and Xcode
Xcode is a polished IDE for developing iOS projects. Ever since the launch of the first Mac way back in the 1980’s, Apple
has been all about ease of use and decidedly intuitive interfaces. That’s what set them apart from the IBM/Microsoft DOS competition back then, and so it is no surprise that mantra is found today, even when looking at developer tools.
Apple has the benefit of a closed environment – they make the hardware, produce the operating systems and have a pretty heavy hand when it comes to allowing an app to be added to the iTunes store. As an example, any iOS developer not adhering to the iOS 7 ‘flat design’ standards will be in a world of hurt come February 1st. Apple has made it clear that if you don’t design towards iOS 7 specs, your app is likely to get rejected.
Android, Eclipse and an Open Source Environment
Unlike iOS, however, Android is open source, meaning that pretty much anyone can take the code and manipulate it to do things that it might not be able to do out of the box. When this is done, the code is known to have been Forked. Forked
code typically isn’t supported as the standard code base, but it is exactly what allows companies like Amazon to produce their Kindle line of tablets. They started with Android, and then made it unique to serve their purposes. Very cool in its openness, but all those forks can gum up the works a bit for the developer. There are a ton of variations in the Android ecosphere, as we discussed in our post about mobile operating system fragmentation a few days back.
Just like the Android Operating System, the recommended development tool, Eclipse, is also open-source. While we’re way past the days when open-source meant buggy and risky – Red Hat, JBoss and Spring Source have all proved it to be enterprise ready – there will always be some aspect that might cause some frustration. After all, the nature of open source has a lot of individual contributors adding to the project.
When you look at Eclipse by itself, it looks fairly polished, but when you try to accomplish a task that might be done by simply dragging and dropping elements in Xcode, the process in Eclipse is not so simple. Let’s use an example common to both iOS and Android development – creating a layout with table views.
In Xcode, the iOS developer can just drag and drop a TableViewController, make a cell prototype, set the outlets and then step up the respective delegate and data sources. Then the developer can edit the dimensions of this table view from the Xcode GUI Builder. Pretty simple.
But in Eclipse, it is a bit more complicated. There isn’t a GUI builder baked into Eclipse, so developers pretty much have to go to the manifest file of a list view and make changes to the dimensions there until the desired result is achieved. Admittedly this is not a massive roadblock, but it is certainly a bump in the road to someone just beginning to learn how to do Android development.
We’re not trying to say that one environment is better than the other, but to instead state that they are definitely different. It is important to consider these types of things if, like our company, your team needs to develop cross-platform solutions for your customers. The timeline on the Android side likely will have different variables to factor in compared to your iOS development timelines. Trust us when we tell you that your client will not know about these issues, and they probably won’t care. It is up to you to set expectations from the beginning and understand how to target the delivery date with all of these cross platform development factors in mind.
So how about you? How do you deal with cross platform development hiccups? Do you take the time to explain the differences to your clients, or do you just assign more resources where they are needed?
Let us know in the comments section below, and if you think this blog is worthy, please share it across your social networks.