iOS vs Android: Battle of Developers
It's an age-old duel: Which platform is better? However, those who expected a clear answer after clicking on the headline will be disappointed. At Ackee, we pull together and respect other approaches, tools and platforms. But the more interesting it was to hear how our team leaders look at both operating systems. Jan Mísař competed for iOS and David Bilík for Android in an imaginary duel for the best platform.
Why did you decide to be the developer of your platform?
🍏 Honza: I think it will be similar for most mobile developers. I bought an iPhone back then, I don't even know why, and I just wanted to try to program something for it.
🤖 David: It was almost the same with me. I originally wanted to start programming for iOS, but I didn't know what it involves. Then I found out that I needed a Mac and an iPhone to do that. :D Which makes sense in retrospect, but I didn't have any of those things. However, I had an Android phone at the time, so I thought I'd try to start with that. I found it interesting to create apps on the devices I use every day. At that time, a class about Android programming opened at FIT, so I enrolled in it. I started to enjoy it within the class, and through contacts from school, I found my first job.
If you could go back in time, would you have chosen the same?
🤖 David: I guess so because even though the development is not perfect, we have developed a relationship full of love and hate with Android in those eight years. I don't know the development on the second platform, so it's hard for me to compare, but I can say that I'm happy with Android.
🍏 Honza: I certainly wouldn't change it. Not so much for those programming reasons, because I'm in the same situation as David, I don't know much about Android development and I can't compare it, but I believe that I could learn it too. However, from that user's point of view, I would definitely not change it. Mainly because of the entire Apple ecosystem, it fits together perfectly, unlike Android, which, by its nature, cannot offer this.
So both of you still use a phone with the same operating system?
🍏 Honza: Exactly. But admit it, David.
🤖 David: Well, don't worry, I was going to. 😬 I bought an iPhone SE about four years ago. My strategy was always to purchase phones from Google, first Nexus and then Pixels, but Google – at least then – wasn't good at it. Even though they had a clean operating system, those devices’ quality did not match the competition, such as Samsung (which I would never buy 😃). So I decided to try the iPhone and see if it was that much better like everyone says. However, after a year and a half, I switched back to Android (Pixel 2) because problems began to appear on the iPhone, and I gave Android a second chance. :) Since then, I'm back on Android, and now I have Google Pixel 4.
How does your cooperation take place? In terms of projects where the application is developed for both platforms.
🤖 David: This is a difficult question because it varies from project to project. We made applications where one platform was ahead, and that proved to be an advantage for us. Typically, this is for projects where we do not supply all parts – such as API. The developers of one platform "dig through it first" and the other platform benefits from this acquired knowledge and both development teams do not have to "fight" it.
In most projects, however, both teams develop the same functions in parallel and try to work together to achieve the same result in application behaviour and match the assignment. Even the best assignment can be interpreted in several ways, and we want both apps to work the same. During testing, we don't want to find out that there are differences, and that we have to fix them. We try to encourage all team members to communicate with each other.
🍏 Honza: I probably have nothing to add to that.
What do you see as the advantages and disadvantages of both platforms from the developer's perspective?
🍏 Honza: The advantage of iOS development is undoubtedly the limited set of devices we develop on. These devices are made only by Apple, iOS only runs on them, and even though there are already many of them today, it is still a limited number. While on Android, there are a lot of those devices from various bizarre manufacturers, from complete low cost to high-end. That's more problematic.
Another great thing about iOS is that most users update to the latest systems relatively early. It means that we are basically developing for the latest versions and can afford to throw away the old ones pretty quickly. This development is then much more convenient than if we have to support some older versions.
The downside is definitely the closed nature of the Apple ecosystem and the fact that Apple is tightening its screws more and more. iOS is already very strictly restricted today, and it can be expected that with the arrival of new computers with Apple Silicon processors, macOS will also move in this direction.
🤖 David: I see one of the most significant advantages in that I can develop for Android on a regular computer that is not a Mac. The prices of computers with macOS are still higher than the more available variants with Windows or Linux, which can be a limiting factor.
With the fragmentation that Honza mentioned, it's more complicated. It is undoubtedly advantageous for users to buy a phone in various price categories and display sizes. Still, for developers, it means that they must support all these devices. At the same time, Google has not been able to ensure such a high adoption of new versions of systems as iOS has, so we must also support versions of the system that are, for example, six years old.
Fortunately, Google is aware of this problem (which it caused in the early days of Android) and tries to solve the backward compatibility. Typically, new things added to the system are not directly part of the system, but a form of a library that can be used on older systems. Of course, this cannot be said about everything they do; however, they try their best.
And pros and cons from the user's perspective?
🍏 Honza: One could say that iOS is safer, consistent, etc. precisely because of the strict Apple guidelines, but otherwise the differences from the user's point of view are already being erased today. When someone buys an Android phone for a price comparable to an iPhone, they get an equally fast and functional device. The difference is gone. However, I would say that the iPhone still has that “cool” factor compared to Android. And I think that having an iPhone, for example, among the younger generation is such a social status matter and Apple maintains its "exclusivity", but otherwise, there is no big difference.
🤖 David: I think the biggest advantage is the one already mentioned – that the user can choose exactly the phone that suits him. If you want to have DualSIM, a physical keyboard or a "foldable" display, there is an Android phone that offers it.
I agree with Honza with that exclusivity, but I think it arose historically. Now the price of iPhones is ± the same to this day, while previously flagships such as the Samsung Galaxy S2 cost ten thousand less than the iPhone. Today, the prices are comparable and sometimes higher for Android than the iPhone.
What about the speed of development?
🤖 David: It depends on the developer's experience. For experienced developers, there will be no difference in the speed of development for a given platform. For example, when I write an application, I take into account that it has to work well on a phone that will have a small display, lower processor power and, for example, a 5-year-old operating system. It simply has to run similarly well everywhere. But for inexperienced people, this can be a significant delay in development, because they don't think about it, and these problems are revealed during testing on various devices.
🍏 Honza: With Apple, we don't have to deal with this.
And what about speed from that user's point of view?
🍏 Honza: For those comparable models, you can't say that one platform is faster. But it may occur in case of the cheaper ones.
🤖 David: Exactly. The users get what they paid for.
How long does it take to debug an application on most devices on the market?
🍏 Honza: Here, it really depends on which application it is. If it's some simple table and pictures, then basically almost no time, because it just works. But if you are dealing with some 3D models, openGL and similar technologies, it will take more work. However, there is no universal answer to this.
🤖 David: Exactly, it depends on what the application's non-standard features are. There is typically a problem with the camera on Android because each phone takes photos a little differently. For one app, we had to deal with one particular phone, which had the photo upside down and mirrored after taking a photo. 🤯 We had to put conditions in the code that let the picture rotate if the application runs on this device. Similar fun happens with GPS position, sensors (e.g. accelerometer) and so on. Basically, every time it depends on the hardware, which differs between manufacturers and individual models, the time for testing increases. If we only display the data that comes to us from the API, then such problems do not arise there. However, I can't give any absolute or relative number because it depends on the project.
What about speed in the context of application publishing?
🍏 Honza: For iOS, it's a little worse. It's related to how I mentioned that Apple is tightening its screws more and more. It is also more thorough in application control. The review process is relatively strict and therefore takes a long time. The situation has improved a lot because now the approval takes low units of days – usually a maximum of two days. But there used to be a few years when the process took seven days and it couldn't go faster. That was very uncomfortable. In this respect, Android is better.
🤖 David: Here, I would just add that Android used to be better. But the question is, what it means to be better because there was no review process before. 😃 Any application that has been uploaded to the Google Play Store has been made available to users. As a result, also potentially dangerous malware apps. However, in recent years, following Apple’s example, Google has begun to implement that review process. But you can see that Apple is far ahead. If there is a snag during approval, the developer will receive an email stating that the app violates one rule out of twenty different ones. They will not say which one it is. It is almost impossible to communicate with a person from Google. Usually, a robot responds. It is then more of an attempt-mistake approach if the update that I release is fixed in precisely what was reproached to it. The world of Android developers has been struggling with this in recent years. Fortunately, we do not have so many problems at Ackee, but we already have our experience.
The releases are your responsibility as team leaders?
🤖 David: The application is usually uploaded to the store by the developers, and the release itself is handled by the client or the project manager. Or at least that's how it is with us on Android.
🍏 Honza: It's the same with iOS.
Is it still relevant that Android could be less secure in terms of security when downloading applications?
🤖 David: By introducing the Review process by Google, there is a great effort to minimise potential threats. Google has strict guidelines for how apps can behave after installation – for example, an app can't display ads in notifications. From this point of view, those applications are not more dangerous than iOS. At the same time, Google is adding new ways to the operating system for users to protect their content, again helping users control their data. For example, one of the latest innovations is that the application can no longer read the GPS position without the user's knowledge. Thanks to these steps, I think that iOS and Android are very similar in terms of security.
However, on Android, it is still true that the user can install the application "sideways", i.e. only via an APK file and does not install it from the Google Play Store. The user has to enable several settings in the system for this, but once they do, they can install an application that would not normally pass through the review process at all. So there is an ever-increasing security risk compared to iOS, but the user has to make a great effort to achieve this.
Let's stay safe – what about data security when I want to store sensitive personal data in the application?
🍏 Honza: We don't have to deal with security that much on iOS, but not because we don't care, but rather because iOS itself is very well secured. Stealing some data from an iOS app is complicated in itself, so we don't have to add many security layers there.
🤖 David: It's similar with Android because apps don't have access to other apps' private data. It's the same as connecting my phone to a computer – I can't read and copy data. It is protected directly by the system. If it is not an application where security is critical (such as a banking application), no additional security layers need to be provided. For example, for these sensitive applications, we can detect whether a user has a "root" phone and prevent them from using our application or other security checks. In general, however, we do not want to restrict users in using our application, so it depends on the particular app which security level we choose.
What architecture do you use? Is it MVVM?
🤖 David: Yes, we use MVVM, an architecture that Google has recommended in recent years as an architecture for developing Android applications and providing supporting libraries, tutorials, etc. However, this architecture only determines the division of layers on the so-called presence, i.e. the display layer. Behind the letter M from MVVM, there is a whole other architecture that needs to be solved somehow. We use the so-called clean architecture on Android, which was introduced a few years ago by Uncle Bob Martin, who is quite a well-known character in the programming world. This architecture allows us to write applications "cleanly" and scalably.
🍏 Honza: We also use MVVM on iOS as the basic design model of the application, which is the foundation for its main logic. But it is, of course, still supported by other design patterns, which are mainly in the "M", as David has already said.
In addition to the fact that we currently use MVVM, we take a good look at the redux architecture and try to implement it somehow. And I feel that Android is looking in that direction as well, but it's still mostly a question of the future.
🤖 David: Yes, we call the redux architecture MVI (Model View Intent), and I think that as soon as we have a stable Jetpack Compose, which is similar to the iOS Swift UI, our architecture will also move in this direction.
How do you program the user interface?
🍏 Honza: We do UI solely in code. We don't use storyboards or interface builders, for many reasons, but that's for a long talk. In any case, Apple recently came up with a completely new UI authoring system – SwiftUI – which loads just those redux architectures. Hence, as it becomes more widespread, we have no choice but to start using that redux architecture.
🤖 David: Here, iOS developers have the great advantage that Apple introduced the SwiftUI to them in such a stable form which could be used straight away. At the same time, Google also introduced a new UI framework based on React or Flutter called Jetpack Compose, but only in the form of a developer preview, a release version will be possible later this year. At this time, we cannot use this framework in production applications because it is not stable. But that doesn't mean we don't examine it in the meantime, because of course, we want to be ready when it's stable. 🙂
However, we have a lot of experience with the definition of UI in code compared to the traditional way through XML in recent years. After we adopted Kotlin in 2017, we implemented the Anko library from JetBrains, which directly defines the UI in Kotlin. It made many things easier for us because we could use all the advantages of Kotlin and we were not limited by XML. Unfortunately, JetBrains has stopped supporting Jetpack Compose Anko due to its upcoming release, and it is currently deprecated. So we go back to XML until Compose is stable. However, because we have experience with defining UI in code, switching to Compose will not be such a leap for us.
Do you also use reactive programming?
🍏 Honza: We've been using it for a really long time. It's been quite trendy lately, but we've basically used it already in Objective-C. At that time, we used Reactive Cocoa, now called ReactiveObjectiveC and succeeded by ReactiveSwift. For historical reasons, we do not use RxSwift, which is definitely more widespread. We use the already mentioned ReactiveSwift, which is based on ReactiveObjectiveC.
🤖 David: We as well have been using it, for four years, maybe more. We started at that time with the most widespread RxJava library, then in version 1. Then we switched to RxJava 2, which is part of most of our applications. In recent years, JetBrains has introduced its reactive programming concept as part of Coroutines, a native framework for parallel programming in Kotlin. It makes sense to use something directly that is part of the language we are developing in, rather than a third-party library, so we've been using Coroutines in applications for the past year.
Manual memory management is no longer being addressed, or is it still a topic? When did that change?
🍏 Honza: The situation on iOS is, I would say, entirely resolved. It happened in iOS version 4 or 5, which is a lot of years ago when Apple added ARC there. Thanks to that, working with memory is much more convenient, it is no longer solved manually. However, you still need to know how ARC works and how to behave so that there are no memory leaks. It is definitely not without our work that it would not be an issue at all.
🤖 David: Android has taken over the concept of Garbage collection from Java, so we don't have to deal with manual freeing memory. But as Honza says, even if the framework solves it for us, the developer must know how this system works. If he handles memory clumsily, a so-called "memory leak" can arise that the garbage collector cannot release. Therefore, parts of the application that will never be released remain in the memory, and over time the system drops such an application due to lack of memory. Fortunately, we have some good tools for finding and eliminating memory leaks, whether from the community or Google, so we're the best we've ever been.
What is the advantage of native development on your platform?
🍏 Honza: So, David, I'll probably leave this question to you, because you're an expert on cross-platform development.
🤖 David: I don't think it necessarily depends on the platform, so I'll answer for both in general. Multiplatform development pays off when the application does not do any "special" things, such as access to the camera, sensors or augmented reality. It just displays the data sent from the server and processes it as easily as possible. At that point, it may seem better to reach for a cross-platform solution, such as React Native or Flutter. I personally have experience with React Native, I have developed several applications in it that are in the stores. Unfortunately, what seems to be the most significant advantage in the beginning – that is, one developer is enough for you to develop an app for two platforms – does not apply at all. I often had to bother Honza here, for example, to help me with a problem that I was solving on iOS. Or someone from our frontend team, because I didn't know how to do something in Javascript, in which React Native is written. Then there is another problematic area that React Native itself brings and that I had to solve myself. Basically, it doesn't just require one person, but you need an Android, iOS and Frontend developer. 😃 The time spent on the app development is not divided by two.
Another option is to use the framework from Google Flutter. So far, we have experience with this only in the form of crowd-learning, where we try to learn the framework together and find out what use cases would be suitable for us and whether it can be used for some applications. But we have only a few weeks of lessons behind us, so we will see what our research will bring us.
And where do you get your inspiration from? Except for the people on the team – that's what everyone always says! :D (Not that it wouldn't be true.)
🤖 David: Now you've stolen my answer. :D
🍏 Honza: I would divide it into two parts. The first is the technical inspiration, which I am increasingly drawing from the team. Many members are technically much better off than me because I'm already devoting myself less and less to programming. And then, of course, from Twitter, the various blogs and podcasts I listen to, like everyone else. The second part is team leadership – I draw the most from what Irena taught us. And I also follow the Red Button network a lot.
🤖 David: Well, I don't know what to add to that. In the technical part, there are newsletters, podcasts, blogs, videos and people from the team who come up with new things themselves, just like Honza. I also listen to podcasts and read books that focus on people and team development. There, I also draw the most from meeting Irena.
Even so, I have to say that the biggest inspiration for me is the other team leaders in Ackee. When I read books or listen to foreign podcasts, it is often a different culture that you cannot completely apply to the Czech environment or Ackee. But if a colleague tells me what works for him in his team, it will probably be similar in our team, and such advice is most valuable.
