Hello, dear friends, long time no see 😂, long time no update of the official account, why not update, is because I have been writing iOS application recently, finally completed my first iOS product development work a few days ago, around the beginning of January next year, this App will be launched, a very interesting application, You can expect that.

Take this opportunity to try to develop iOS, write an article to share the experience of developing iOS. If you are an Android engineer like me, I hope my experience can help you.

As the title says: What’s it like for an Android Engineer to develop iOS? In this post I will compare and contrast my development experiences on both sides of the Android and iOS platform.

Development of language

At present, the mainstream iOS applications are using Swift development, Swift has developed to Swift5, as for the language, it is highly recommended to directly use Swift as the development language, as for OC, who still uses OC? If you were an iOS developer in the first two years of your life, you would have had a lot of headaches with Swift, because with every major Swift release, the API would change so much that upgrading would be a pain. I used Swift4 for iOS development at the earliest. In my impression, there were almost no major changes when I upgraded Swift5. Currently, THE API has tended to be stable, so if you want to try iOS development, Swift is the preferred development language.

I switched from Java to Kotlin to develop Android in 2017. I still remember that when I was writing Kotlin, I always asked my iOS colleague next door for any code I could not write. Since Kotlin and Swift syntax are really similar, if you have Kotlin development experience, you should be able to read Swift code without any problems.

So as an Android engineer, thanks to Kotlin, the language doesn’t stop you from trying to develop iOS. And no matter what language it is, it’s the same programming paradigm, it’s the same data structure, it’s object-oriented programming, it’s the same architectural pattern, it’s just the API that’s different, and the API problem is better solved, just look up the documentation.

For me personally, I didn’t spend any time learning Swift when I was developing iOS because it was so much like Kotlin that it cost almost nothing to migrate.

Rating Kotlin and Swift in terms of flexibility and simplicity: Koltin is a 9 or higher, Swift is an 8 at best. Or maybe I am not a good student, when I often write Swift code, I always think that if Kotlin this code might be written more cool, for example, the following empty judgment, you can feel the difference between Swift and Kotlin:

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

if let user = user {
    print(user)
}
Copy the code
val user: User? = User(id = "1", name = "2") user? .also {print(it)
}
Copy the code

It’s almost as neat, but I’m using Kotlin, right? There is a feeling of one stroke when writing down, while Swift needs to write an “if” and “let”. There are many small details like this, and if you write too many, you will sigh “Kotlin cool”.

I prefer Kotlin in terms of language.

IDE

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, 4.0 has many updates and upgrades, If you want to keep up to date on what’s going on in Android Studio 4.0, check out my previous post: Android Studio 4.0 Update.

We say first normal experience, writing code, have to say the Xcode really often convulsions, highlighting every now and then, click details to view the API definition, often appear a big question mark, prompt can not find, variable jump is smart enough, often click to jump to another in the class of the same variable name, It is not the actual location of the variable. I once had a painful problem where Xcode could not compile the modified code and had to be reinstalled, which was really frustrating.

At the same time, if you write SwiftUI with Xcode, there is a fatal bug, that is, the error message will indicate the wrong line, which makes me very painful when I check the error.

In contrast to Xcode, Android Studio’s development experience is really great, probably based on IntelliJ. Jetbrains’ ides are great, stable and powerful, and at least I’m comfortable with Android Studio, or maybe it’s because of my preconceptions, but from what I’ve learned, Xcode crapshoot is a common and often teased issue among iOS developers.

Let’s talk about third-party dependencies. Since the inception of Android Studio, we have used Gradle to rely on third-party libraries. Before AS 2.0, one of the biggest obstacles to third-party dependencies was network problems. Xcode most commonly uses Pod to install dependencies. Pod is a third-party dependency platform. In 2018, Xcode launched its own third-party dependency tool, Swift Package Manager, which directly pulls codes through Github, which is much more convenient than Pod. In terms of third-party dependencies, there is not much difference.

Due to iOS completely closed source, I encountered some problems during development. Sometimes I didn’t know where to start, and when I reported an error, I threw a stack address directly, which left me completely confused. Android is open source, so when we debug, we can step by step debug into the source code, in solving the bug above a lot of convenience.

On the IDE side, I prefer Android Studio.

Declarative UI

This year, Google I/O and Apple WWDC have both released declarative UI components, SwiftUI and JetPack Compose. For those of you who are interested in JetPack Compose, check out this article.

Most of my new products are completed using SwiftUI, and part of them use UIKit. The syntax of SwiftUI, JetPack Compose and Flutter UI is very similar. Some people complain that the declarative UI code is too nested and messy. Personally, I don’t think this is a problem at all. Abstract and composition are the most basic professional qualities a programmer needs to have. Thinking carefully about how to design code before writing can largely avoid the problem of nesting bloat.

The biggest convenience of declarative UIs is that what you write is what you get. Dramatically reduces the amount of code. If it took a day to write a complex interface, using a declarative UI can cut it in half.

Although I like declarative UI very much, SwiftUI, which has been written for so long, has obvious defects at present. SwiftUI does not fully realize all functions of original UIKit. If SwiftUI cannot realize all functions, it needs to define a Warpper of UIKit. But that doesn’t completely solve the problem, there are still some unforeseen bugs with SwiftUI mixed with UIKit.

At the same time, SwiftUI has just been launched, and many best practices are missing. Most people are in the pit stage, and there are many bugs, which cannot be solved. I opened a name on Github called: SwiftUIBug library, to record so far I use SwiftUI encountered bugs, and provide solutions to avoid others continue to step on the pit, interested friends can continue to pay attention to some.

Why are you talking about SwiftUI? What about JetPack Compose?

B: well… Let’s just say, SwiftUI has at least a few pages of documentation, while JetPack Compose only has a few pages. Besides, I have tried the official demo, and the current completion level, not to mention the production environment, even the demo has a lot of bugs. At least in a production environment, SwiftUI is fine for writing simple pages.

So in my opinion, for iOS development, SwiftUI can be used for simple pages, and UIKit should be used for complex ones. After all, if SwiftUI does not support it, it will definitely cheat you. For JetPack Compose, we’ll at least wait for the official version to see how it’s done. It’s still early.

By the way, SwiftUI supports iOS 13 at least, so those who want to use SwiftUI should be careful. JetPack Compose does not have this limitation. Since the emergence of AndroidX, Android has been avoiding API updates and updating with the release of Android version. Use a separate third-party library.

I called SwiftUI for declarative UI.

The product experience

I’m on iOS, and I think iOS is still the most usable system out there, both in terms of App experience and ecology. In terms of the experience, iOS feels reliable. For example, iOS supports a lot of UI details well, whereas Android always feels like a work in progress.

Lag is a very common problem on Android, even if you are always careful to write code, there will still be a lag problem, and iOS really as long as the code is not too rough, there is almost no lag.

If you observe carefully, the experience of the same App on iOS must be better than that on Android. This has nothing to do with the developer’s ability, and the system difference is reflected here. There is no denying that iOS has many excellent apps with great interaction and experience. Before, I searched the whole Google Play to find an app that can match the excellent experience of iOS, but unfortunately there is none. Even Apple Music, which is also available on both Android and iOS, has a significant gap between the two.

API experience

In recent years, the iOS and Android sides have been borrowing from each other and converging in functionality. IOS’s API design is consistently very forward-looking, while Android’s fragmentation has left a lot of holes, and Android developers are really suffering. According to my personal feeling, iOS API is very mature, the development is much faster than the overall Android, many effects and requirements, iOS itself has a good solution, we just need to focus on the requirements. Android is like a semi-finished product, everything has to be studied for a long time, iOS can be pulled out of a prototype in minutes, Android also needs to helplessly painful technical research. As far as shadows and frosted glass are concerned, Android can do it too, but it’s much less effective.

IOS UIKit uses AutoLayout for Layout. Although it is a bit complicated to write, the API is very uniform, and all THE layouts between UIs can be bound with constraints. In contrast, Android has many layouts, and different layouts have different apis. Constraintlayout came out on the heels of iOS, which made it a lot easier to use. Constraintlayout if you haven’t already, you’re really behind.

Android gives me the impression that Google is throwing a library of components at you, and they probably don’t know how to use it, how to do it, and it’s up to developers to step on their own.

In addition to providing you with a library of components, iOS also has strict specifications and recommendations on how to do it, and it doesn’t cost a lot of learning. Of course, thanks to the closed source feature of iOS, although not as free as Android, it can guarantee the quality of your application.

The last

Although Android is currently the world’s largest mobile operating system, the quality and ecosystem of software is still far behind iOS. The above is my recent experience of iOS development, which is entirely based on my subjective feelings. If you have different opinions, you can leave a message and share them. In the later post, in addition to Android and Kotlin, I will continue to share other things I am interested in, which is the slogan of this public account: Explore interesting new things.

Finally, thanks for your attention!