)
)
I just spent a week developing my first iOS app:
There is quite a rivalry between supporters when it comes to deciding between Android and iOS apps. This is largely linked to the different restrictions that apply to each platform. But the main restriction of developing an iOS app is that you can only do it on macOS X (not Windows or Ubuntu).
Even though you could set up a Virtualbox and install macOs, it’s not really worth it as it comes with a lot of drawbacks.
For example, you’d need: >4 GB of RAM, an Intel i5 or i7 compatible CPU, and >10 GB of free disk space. On top of the hardware restrictions, there are also legislation restrictions.
As well as this, the Objective C language (which I have no idea how to code with) was another reason I never tried iOS developing.
But things changed slightly. The new official language of iOS app development is Swift, which has a lot of similarities with Kotlin, a fully supported programming language by Google on the Android Operating System and widely used by the Android team.
The IDE (Integrated Development Environment):
So, after a couple of hours setting up the Xcode (which requires an Apple ID), I finally managed to start my mobile app development project.
My first impression was that XCode is inferior to its Android counterpart; although they both consume RAM like there’s no tomorrow, there’s a couple of things that I prefer on Android Studio…
First off, Android Studio’s code autofill and recommendations are way better and more responsive than those on XCode.
Also, one of the other things I don’t like about XCode is that when you click on a class, it opens it on the main screen but the previous classes are hidden, so you cannot have multiple tabs.
Android vs iOS app development structure:
Android applications are primarily broken into two sections: the source code (java/kotlin) and the res folder resource (images, XML layout files, strings, screen density, drawable, colours).
A good technique to use when developing is to split the src/main folder to use top-level categories for activities, fragments, views, adapters, models and managers.
In iOS, all the files are in the same folder, and then you can set a subfolder for the controllers, views and models.
Another similarity in the project structure is the AndroidManifest.xml file. This file is the equivalent of the Project-Info.plist file on iOS, and it stores information for activities, application names, and set Intents (system-level events, permissions) that the application can handle.
Designing for Android vs iOS:
To create a new view/screen in Android we use the xml files. In iOS they use a storyboard, which I like as an idea because you can see how the screens link with each other, but this functionality means that it takes more time to achieve what you want to do.
The new ConstraintLayout in Android really resembles the restrictions you add in iOS. In Android app development, you can write the code straight away, whereas in iOS you’re forced to used the graphic user interface (GUI).
The next thing that I noticed is that the error messages for iOS are quite unhelpful, and the information they provide is quite vague.
Adding layouts/views is simple in both cases, as both IDEs support drag-and-drop functionality.
Implementing a custom layout in XCode reminded me a little bit of Android, because you create a custom view on your Table View object, then you override the UITableViewCell to initialise the view. Similarly, in Android Studio, you need to create a holder that will initialise the custom view and adapter that will be passed to the list/recycler view.
In the following screenshots you will see how the two operating systems create a button in the center of the screen with padding.
)
)
)
Searching online for examples and code for XCode was more difficult – maybe because my search terms were not 100% iOS-specific, since I didn’t know the exact name of the view, but even knowing the name won’t get you a code which can simply be copied and pasted.
You will need to rewrite all the code… which is like reinventing the wheel every time…
"… there’s a lot more guidance, examples, documentation and copy-paste code for Android designs compared to iOS ..." null
There are also things that I loved about developing an iOS app. One of these was the iOS simulator, which is unbelievably fast! This feature is way way better in iOS than Android.
Moreover, it was already there, it didn’t require any action by me. In contrast, Android requires 3 really straightforward steps.
Let’s also clarify the difference between emulation and simulation.
Emulation is the process of mimicking the outwardly observable behaviour to match the behaviour of another object. So in practise, this means that the internal state of the emulation mechanism may or may not accurately reflect the internal state of the object which it is emulating.
Simulation, on the other hand, involves modelling the underlying state of the object. The end result of a good simulation is that the model will be identical to the object which it is simulating.
“ … it's certainly true that the iOS simulator is better than the Android emulator ..." null
Android vs iOS coding:
Similarly to MainApplication in Android, there is AppDelegate in iOS with the following functions:
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool func applicationWillResignActive(_ application: UIApplication) func applicationDidEnterBackground(_ application: UIApplication) func applicationWillEnterForeground(_ application: UIApplication) func applicationDidBecomeActive(_ application: UIApplication) func applicationWillTerminate(_ application: UIApplication) func applicationDidReceiveMemoryWarning(_ application: UIApplication)
Again, we find a lot of similarities between these two, as MainApplication on Android extends the following methods:
fun onConfigurationChanged( newConfig: Configuration)
fun onCreate()
fun onLowMemory()
fun onTerminate()
fun onTrimMemory(level:Int)
We can see that 3 main functionalities are similar:
onCreate = application,
onTerminate = applicationWillTerminate,
onLowMemory = applicationDidReceiveMemoryWarning.
Instead of Activities and Fragments, iOS has UIViewController which overrides the following functions:
fun viewDidLoad()
fun viewWillAppear()
fun viewDidAppear()
fun viewWillDisappear()
)
While in Android the Activities look like this:
fun onCreate( savedInstanceState:Bundle)
fun onStart()
fun onResume()
fun onPause()
fun onStop()
fun onDestroy()
)
Again, you’ll notice that these two diagrams share a few similarities:
)
)
You’ll notice even more similarities between the Fragment and UiViewController life cycle:
)
If you want to add an interface, you should use the keyword protocol, but the method definition is the same:
interface MyListener { fun callback(param:Int) }
protocol MyListener { func callback(param: Int) }
As you may notice at this point, even though they are not implementing the same functions and they recognise different states of the app, they also have a lot in common. This can be translated as a sign that we could use to create a solution by doing the same thing.
“ … knowing one of the programming ways makes it easier to learn the other" null
Data storage options:
The Data Storage Options available on Android are also very similar to what is available on iOS:
Shared Preferences <-> NSUserDefaults
In-memory objects
Saving to and fetching from file structure via the internal or external file storage <-> saving to the documents directory
SQLite <-> Core Data
Google Play Store vs the App store:
When it comes to submitting your app to the Google Play and App Store, Google has a one time $25 registration fee which you need to pay before you can upload an app. Apple charges $99 per year.
Both the Google Play Store and App Store share the same revenue sharing conditions – 70% goes to the developers, and 30% of revenue goes to the store.
Uploading an app in the App Store is considerably more time consuming. Both platforms have a violations policy prior to publication, but the App Store is far more detailed, which can sometimes result in your app being rejected by one platform and accepted by the other.
Apple claims to review and test the submitted apps manually, which is why it takes 2 days. The official sources state that 50% of apps are reviewed in 24 hours, and over 90% are reviewed in 48 hours. Thus, it rarely takes more than 2 days to get your app approved or rejected. Until recently, it took over 7 days to review and approve an app.
Google uses an automated algorithm to pre-analyse all submitted apps for obvious content violations or malware. After the app passes this screening process, it’s manually tested by a team of reviewers. This means that the process of publishing an app to the Google Play store is usually a lot faster than publishing an app to the App Store.
Both platforms have a sign-in process using their EDIs (XCode and Android Studio). Both require you to provide the app information and assets, including icons, screenshots, and descriptions. However, the App Store does not offer push app installation systems at all. The iPad and iPhone users have to do it manually for their devices.
Al in all:
It only takes a couple of hours before it’s live in the Google Play Store, and it simply requires a one-off payment of $25.
Published on 8 May 2018, last updated on 25 September 2024