Codemate news
6.11.2016
Winter is coming.
There’s something special in physical things, especially having worked with digital solutions for so long. That’s why we wanted to send you an original postcard card in snailmail to let you know what’s going on at Codemate.
When I started Android development, the development environment (IDE) was Eclipse which I used on other Java projects as well. Then Google made developers move the Android projects to Android Studio. I found that a major upgrade, Android Studio being more stable and a better IDE overall for this purpose.
When starting with iOS development, first thing that I needed to get familiar with was Xcode and all its shortcuts. It’s quite a deep learning curve but manageable. Application project configuration seemed somehow clearer in Xcode if compared to an Android Studio project which is mix of files you just need to know first ( f.e manifest and gradle build definitions). Xcode UI for project management is more intuitive. Handling application info and capabilities are clearer than in Android projects.
From Android development experience I was familiar with UI definition style in XML and how all the app resources are defined under the organized res-folder. Although it required thorough knowledge in the application code and the UI flow, I was happy with using the resources in Android projects and because of that it was a thing to miss while jumping into the world iOS and Xcode.
After a short while, I noticed a massive boost in UI development convenience when using storyboards. Here’s a pretty good tutorial on storyboards, scenes and segues. Storyboard provides a main application flow even if you’re not familiar with the app itself i.e it is developed by other developer. It’s a great way to organize the UI visually, with less code written manually.
As a side effect, if the iOS project is based on an old version of iOS, there is not necessary a storyboard and the UX side is built with code and xib-files, the idea being similar to Android with xml layout files. These older apps may require UI porting into storyboards, which doesn’t seem like a walk in a park.
The simple storyboard of the audio story app I developed.
The UI definitions seem to have quite a similar style between the platforms. However there is a one magical word that sets them apart: Constraints. While building the UI you will most likely face constraints, which are relative dimensions of the UI elements. After my experience it is one of the highest speed bumps while moving from Android to iOS, if not counting totally different coding languages.
As I was familiar with Android’s ready-to-use layout container system, I really missed that in iOS development. iOS development is based on constraints and setting up dimensions between UI components and the view. I needed to force myself to do a paradigm shift.
There is also a massive difference with provided UX components between the platforms. There is a huge set of ready-to-use UI components on Android side, but totally missing some of them in iOS. Sure, they have their own. However, it is relatively easy to start using external libraries & ui components in both cases.
To set up external libraries into Android projects I used Gradle build system and dependency definitions which were quite clever and easy to handle. Basically, I just defined a library which will was loaded to the current Android project. Nowadays Gradle is the default tool for this, included in the Android Studio.
The equivalent tool in iOS development is CocoaPods. Getting CocoaPods running for the first time felt a bit complicated, but it is quite a simple tool to use after the first configuration is set up correctly.
Building for Android is usually quite straightforward process: just select the device and build.
The steps are the same with iOS but there is one major advantage: building and running a simulator is a lot faster than on Android. However, Google just provided a totally new emulator version and it looks promising.
Building for release is profoundly different between the two platforms. When building for Android it is a lot easier. It requires only a few steps of signing a package with a valid keystore. In most cases you’re able to test release the package with any Android powered device. With iOS I needed to do a lot of configuration with the the Apple account, application provisioning profiles, devices etc. Xcode tries to tell if something is missing or misconfigured and sometimes it could fix them too, but I wouldn’t hold my breath with that. ;-)
Development for iOS felt first a little tricky due to the deep learning curve faced immediately when building apps with Android development background. Even when I had a some basic knowledge in iOS development from past and had attended an iOS development course, it required study on what things had changed between the iOS versions and tools from those days. Probably the biggest thing was getting used to Objective-C coding syntax after java.
Next step for me will be iOS development with Swift.
Get a wrap-up of the stories and insights we produce. Maximum of one e-mail per month.
Subscribe to our newsletter!