• What I would like to know before I code my first iOS application in Swift
  • This article has been authorized by the original author Bartłomiej Kozal.
  • The Nuggets translation Project
  • Translator: jiaowoyongqi
  • Proofreader: Cbangchen, Owenlyn

Last week, my brother and I created our first iOS app in Swift. Through this article, I would like to share what I have learned from this process.

I am an engineer with six years of experience in website application development, and master Ruby and JavaScript. In the last three months, I have devoted myself to learning Swift programming language.

Objective – C is dead?

Swift is a programming language created by Apple, one of the world’s largest companies. That suggests a number of things: First, Apple isn’t shy about introducing major updates to its platform. What you need to know is that by major updates, I mean a series of updates including priority updates.

For example, at the last WWDC, Apple announced that most of the apis would be renamed. Swift is a programming language based on objective-C, which was originally designed for iOS developers. Also, WWDC for me is like taking a week off to enjoy interesting presentations and presentations. Even so, Swift is one of the most remarkable programming languages I’ve seen with open learning resources. Take a look at the related projects.

Swift vs DHH;

Does that mean Objective-C is dead and you don’t need to learn? Almost. I can guarantee that most books in the library and most code cases on the Internet are written in Objective-C. But interestingly, as I was programming through Swift, I learned more and more about Objective-C. Now I can understand Objective-C code pretty well.

Another thing you need to know is the huge number of internal interfaces that you might be surprised at when you’re ready to call an API. You can build basic features like cameras, microphones, gyroscopes, accelerators, and touch screens by invoking phone functionality, much easier than programming for web pages.

The development tools

Apple’s XCode is a magic box. It contains everything you need to develop an iOS app: a code editor, an interface builder, a data manager, a debugger, and basic build tools.

Unfortunately, these tools have many flaws. Especially when using the interface builder, I always have a black question mark in my mind. When I first used the interface builder, I always said, “Wow! I can create interfaces just like I would with Sketch or Photoshop.” But it’s not all that nice, and the interface builder is more of a quixotic creation to avoid writing code than a simple interface design tool.

It’s not uncommon for you to do an operation on the interface builder and nothing happens. There are a lot of things you can’t predict, you just have to understand it; For example, you can simply click on the error message to remove the incorrect constraint warning. Also, when you remove properties or events, always remove references to bindings from the storyboard. If you don’t do this, you might not get any error warnings during programming, but you might crash when the simulation runs the App.

You need to find a balance. In my experience, the interface builder is primarily designed to apply the main page flow, as well as layout interface elements, with seamless links between different view controllers (rather than between buttons and view controllers). Customize UI elements using Settings stored in code and inheriting existing interface elements.

IOS apps obviously have more GUI programming than web programming. My advice is to learn more about the basics, such as what vector graphics are and how the transformation is implemented. Knowing this will help you in the future.

You always need to test your app on a real device. Clicking with a mouse on the simulator feels completely different than touching with a finger on a phone.

The close button makes sense in the simulator, but sliding down to close is more intuitive on the device.

The official dependency library manager has not yet been released. But there are two third-party communities you can choose from: CocoaPods and Carthage. I’m currently using the former and haven’t had too many problems so far.

Tip: Don’t rely too much on undo. XCode doesn’t have the ability to click CMD +z to go to the corresponding page, so you can’t see where the changes are made. It is recommended that you use Git and keep a record of your changes.

Differences between Web programming and iOS programming

When you’re creating a new project, you’ll notice that there are no rules. Compared to Ruby apps with similar code structures, iOS apps don’t have a hard and fast format for your code. Every developer can build the app as they see fit. But I honestly don’t like it that way. Ruby’s specification makes it easier to find where your code is.

So where should I put my newly created classes?

Another thing I’ve found is that features that are easy to implement in a Web application are not easy to implement on the App side, and vice versa. For example, having elements arranged vertically is a simple operation, whereas changing the font of the label title is not.

Cool UI actions, page jumps, and gestures are much easier to implement using iOS apis than JavaScript/CSS.

Another big topic is limited mobile resources and optimizing performance. You can’t improve the performance of your application by piling on cheap hardware. And apps are limited by the phone’s own power. Using the CPU to optimize the performance of an application is a common practice, but the results vary widely from phone model to phone model, which is also a problem.

Calling an external API is a tricky business. There are already too many examples of extreme errors that can cause a black screen or flash back if not called properly.

Static typing and real-time precompilation are very useful tools and can help you avoid a lot of errors. I like the optionals feature of the code, which ensures that you don’t leave out unnoticeable nil values. I now miss optionals when DEVELOPING web apps with ActiveRecord.

On the other hand, I miss components that have functionality built into the Ruby standard library. You can call map(), filter(), reduce(), and lots of other useful code. Again, there are often differences between different apis in an interface system, which you need to be aware of before designing. I’ve even seen interfaces with different names that do the same thing, and one of them is just an older version of another.

Release application

I have to say one thing: it took longer to get the app ready to launch than it did to develop it! Pay attention to this, because building an app is more than just writing code.

The App Store is the only official platform where you can publish your own iOS apps, and apple pays a 30% fee for each transaction. That may not seem like much, until you look at the sales report. Even more surprising, when you add in income tax payments, you get only 50 percent of sales. Take into account other expenses and the average price on the App Store (most apps are free or cheaper than a cup of coffee) and you’ll find that your product needs to be well-positioned and well-run to be profitable.

Apple doesn’t give you enough tools to support your campaign. You can create 30-second advertising videos, up to five screenshots, and the app title, introductory text, and search terms, all of which are limited to 100 characters. The rest is up to you. I find it annoying that they don’t provide keyword statistics tools, so you have to use third-party tools.

The final detail is the application review time. Once you upload your app to Apple’s servers and click the “Publish” button, you’ll have to wait twice, once for it to be reviewed and again for it to be reviewed. So don’t expect your new product or patch to appear on the App Store the day after submission.

Learning materials

To close, I’d like to list some of the books and resources I’ve read:

Design & Code – I started with this tutorial, which consists of 5 books (three of which are directly about development). This tutorial is perfect for designers who have never worked with code before. It’s not the best choice for everyone to get started, as some of the details are outdated, but I still recommend it. There are video versions of each chapter.

Stanford CS 193P Lecture on iTunes U — I think this is the best introductory tutorial because it covers everything you need to know about programming in detail. This is not for all novices, however, as it requires coding experience. This tutorial is free and up to date (Xcode 7, Swift 2 and iOS9). There will be an after-class exercise at the end of each chapter to make sure you have learned something in the lesson.

Hacking with Swift – This book contains everything you need to know about Swift and iOS development. It works beautifully with the last book. Each chapter is a mini-project to explain and practice an API. You may find this book too thick to read and boring, but it’s a great value for money.

Pro Swift – Only write about the advanced knowledge of Swift. Each chapter will be accompanied by an instructional video in which the author will explain the knowledge through examples. This is definitely a must-read resource for improving your Swift capabilities. Highly recommended!

100 Days of Swift — 40 real Swift programming cases taught by video. The author shows a lot of “strange and clever” and a lot of practical development techniques. Although this tutorial is intended for beginners, I don’t recommend it to beginners because it lacks explanations of basic concepts. This book is worth reading if you really know and are comfortable with Swift or iOS.

IOS Developer Library – the main resource I use now. The hardest part about getting started is not knowing where to start. Here you can see how Apple developers write and organize code. But you need to know that some of these examples are written in Objective-C and are a little bit out of date. It is also the only source of up-to-date API information.

According to the blasting! That’s me on the right!