What is the experience of Android engineers developing IOS?


Hello haven’t met in a long time, friends, haven’t updated the official account for a long time, why didn’t update, because I recently wrote iOS application, and finally finished my first iOS product development in the first few days. Probably at the beginning of next January, the App will be on-line. What a very interesting application you can expect.

Just through this opportunity to try to develop IOS, write an article to share the experience of developing IOS. If you were an Android Engineer like me, I hope my experience can help you.

As the title says: what is the experience of Android engineers developing IOS? In this article, I will compare my different development experiences on Android and IOS.

development language

At present, mainstream IOS applications are developed using swift. Swift has developed to swift5. For language, it is highly recommended to directly use swift as the development language. As for OC, who still uses OC now? If you were an IOS developer in the first two years, you may often have a headache for swift, because every major version update of swift will make great changes to the API, which is very painful to upgrade. Swift4 was first used in IOS development. I have the impression that there were few major changes when upgrading swift5. At present, the API has tended to be stable, so if you want to try IOS development, swift is the preferred development language.

Similarly, Android has also experienced the switching of development language. In 17 years, I switched from Java to kotlin to develop Android. I still remember that when I was writing kotlin, I asked my IOS colleagues next door for code that I couldn’t write, because kotlin and swift syntax are really similar. If you have kotlin development experience, Then you should be able to read swift code without obstacles.

So as an Android Engineer, thanks to kotlin, the language will not be an obstacle to your attempt to develop IOS. And no matter which language, it is the same programming paradigm, the same data structure, object-oriented programming and similar architecture mode. The only difference is API. The API problem is best solved. Just check the document.

Personally, when I was developing IOS, I didn’t take the time to learn swift, because it was so similar to kotlin that it almost cost-free migration.

If you score kotlin and swift from the perspective of flexibility and simplicity: I give koltin 9 points or higher, while swift can only get 8 points at most. Or maybe I’m not good at learning. When I often write swift code, I always think that kotlin’s code may be better. For example, the following empty judgment, you can feel the difference between swift and kotlin:

let user: User? = User(id: "1", name: "2")

if let user = user {
// Kotlin
val user: User? = User(id = "1", name = "2")

user?.also {

Although it’s almost as concise, I use kotlin one? There is a feeling of finishing writing at one go, and swift wants to write an if and a let. There are many small details like this. If you write too much, you will sigh that kotlin is cool.

I prefer kotlin in terms of language.


IOS uses Xcode as the official ide. The latest version is 11.3. Android uses Android studio as the official ide. The latest stable version is 3.5.3. The latest preview version is 4.0. There are many updates and upgrades for 4.0. If you want to know the latest progress of 4.0, you can see my previous article: the latest progress of Android Studio 4.0.

Let’s talk about the normal use experience first. When writing code, we have to say that Xcode really often gets wind, and the highlight disappears from time to time. When clicking on the details to view the API definition, a big question mark often appears, indicating that it can’t be found. The variable jump is not intelligent enough. We often Click to jump to another class with the same variable name, It’s not where this variable is really located. I once encountered a very painful problem. Xcode can’t compile and take effect on the modified code, so it can only be reinstalled. It’s really a big headache.

At the same time, if you write swiftui with Xcode, there is a fatal bug, that is, the error message will be prompted in the error line, which makes me very painful when troubleshooting errors.

On the contrary, compared with Xcode, the development experience of Android studio is really great, which may be based on IntelliJ. The first impressions are strongest, very stable and powerful. At least I have a comfortable feeling with Android Studio, or maybe because of my preconceived ideas. But according to my previous understanding, Xcode is the acknowledged problem of iOS developers, and they are often heard to make complaints about JetBrains IDE.

Let’s talk about third-party dependency. Gradle has been used to rely on third-party libraries since the birth of Android studio. Before as 2.0, the biggest obstacle to third-party dependency is the network problem, which often fails to complete compilation due to poor network. The most common use of Xcode is to use pod to install dependencies. Pod is a third-party dependency platform. In 18 years, Xcode launched its own third-party dependency tool, swift package manager, which pulls code directly through GitHub, which is much more convenient than pod. In terms of third-party dependence, there is little difference between the two.

Because IOS is completely closed, I encounter some problems during development. Sometimes I don’t know where to start. When I report an error, I directly throw out a stack address, which makes me look confused. Android is open source, so we can debug to the source code step by step when debugging, which is much more convenient in solving bugs.

In terms of IDE, I prefer Android studio.

Declarative UI

This year’s Google I / O and apple WWDC launched declarative UI components, swiftui and jetpack compose. I wrote an article before: the latest progress of jetpack compose. Interested students can have a look.

Most of my new products are completed using swiftui, and some use UIKit. After use, the declarative UI is really convenient, and the syntax of swiftui, jetpack compose and fluent UI is also very similar. Some people complain that the declarative UI code is too nested and messy. Personally, I don’t think it’s a problem at all. Abstraction and composition are the most basic professional qualities of a programmer, Thinking carefully about how to design code before writing can largely avoid the problem of nesting bloated.

The biggest convenience of declarative UI is that what you write is what you get. It greatly reduces the amount of code. Previously, if it took a day to write a complex interface, using the declarative UI will save you half of your time.

Although I like the declarative UI very much, the current defects of swiftui, which has been written for so long, are also obvious. Swiftui does not fully realize all the functions of the original UIKit. If swiftui cannot be implemented, you need to customize a UIKit warper, but this does not completely solve the problem. There are still some unforeseen bugs in the mixing of swiftui and UIKit.

At the same time, swiftui has just been launched, and there are no many best practices. Most people are stepping on the pit. There are many bugs that can not be solved. I open a call on GitHub:SwiftUIBugTo record the bugs I have encountered so far using swiftui, and provide solutions to avoid others from stepping on the pit. Interested friends can continue to pay attention to some.

Having said so much, why are you talking about swiftui? What about jetpack compose?

Well… Let’s say, the swiftui document has at least several pages, while jetpack compose has only a few pages. Moreover, I have experienced the official release of the demo. The current completion degree, not to mention the production environment, even the demo has many bugs. At least it’s OK to use swiftui to write some simple pages in the production environment.

So my view is that if a simple page in IOS development can be implemented with swiftui, use UIKit for complex pages. After all, if swiftui is not supported, it will definitely kill you. For jetpack compose, we should at least wait for the official version to see how the completion is. It’s still early.

By the way, swiftui supports IOS 13 at least, so students who want to use it should consider it carefully, while jetpack compose does not have this restriction. Since the emergence of Android x, Android has been avoiding API updates and updating with the release of Android version, and adopts an independent third-party library for use.

In terms of declarative UI, I call swiftui.

Product experience

In this regard, I stand on IOS. I think IOS is still the best system at present, both in terms of APP experience and ecology. As for the experience, IOS feels trustworthy. For example, for many UI details, IOS supports very well, while Android always gives people the feeling of semi-finished products.

Caton on Android is a very common problem. Even if you write code carefully all the time, there will still be Caton problems. As long as IOS is not too rough code, almost no Caton will occur.

If you observe carefully, the experience of the same app IOS end must be better than that of Android end, which has nothing to do with the developer’s ability. The system difference is reflected here. It is undeniable that IOS has many excellent applications and great interaction and experience. Before, I searched the whole Google play to find an application comparable to the excellent experience of IOS, but unfortunately not. Even apple music, which is also launched on both Android and IOS platforms, has a lot of difference between the two.

API experience

With regard to the development in recent years, both sides of IOS and Android have been learning from each other and their functions tend to be consistent. The API design of IOS is consistent and forward-looking. In the past few years, Android has really left a lot of holes due to fragmentation. Android developers are really too painful. According to my personal feeling, IOS API is very mature, and its development speed is much faster than that of Android. There are many effects and needs. IOS itself has good solutions. We just need to focus on the needs. Android is like a lot of semi-finished products mentioned before. You have to study everything for a long time. IOS can roll out a prototype in minutes. Android still needs to do technical research. As for the shadow and frosted glass, Android can also do it, but the effect is much worse.

AutoLayout is used for layout in IOS UIKit. Although it is cumbersome to write, the API is very unified. The layout between all UIs can be bound by constraints. On the contrary, Android has many layouts, and different layouts have different APIs. Fortunately, it launched constraintlayout after IOS, which is much more convenient, If you haven’t used constraintlayout, you’re really behind. Don’t say you can’t learn, you must learn this.

Android gives me the feeling that Google has thrown you a pile of component libraries. As for how to use them well and what the effect is, they may not know. Developers need to step on the pit by themselves.

In addition to providing you with component libraries, IOS also strictly formulates specifications and recommends what you should do without high learning costs. Of course, this also benefits from the closed source feature of IOS. Although it is not as free as Android, it can ensure the quality of your application.


Although Android is the mobile operating system with the highest share in the world, the quality and ecology of software are really far from IOS. These are my recent experiences in developing iOS, which are entirely from my subjective feelings. I have different opinions to share with you. Besides pushing Android and Kotlin related concerns, I will continue to share other things I am interested in, which is slogan of the official account.  Explore interesting new things

Finally, thank you for your attention!

What is the experience of Android engineers developing IOS?

Recommended Today

Swift advanced (XV) extension

The extension in swift is somewhat similar to the category in OC Extension can beenumeration、structural morphology、class、agreementAdd new features□ you can add methods, calculation attributes, subscripts, (convenient) initializers, nested types, protocols, etc What extensions can’t do:□ original functions cannot be overwritten□ you cannot add storage attributes or add attribute observers to existing attributes□ cannot add parent […]