When we think about developing for iOS, most often a five-digit sum of the input threshold arises in the head: at least you need an iOS device on the latest OS and Mac version. If you are already writing for iOS, you probably know the alternatives, and if not, look, suddenly it will come in handy? The overview post below is for this case. Under the cut you will find quite simple information, so if you want hardcore, you are not here!
So, we have an iOS device in our hands, an idea of ​​an application in our head, a desire to quickly acquire new knowledge in our hearts. Before us are three paths, just like an epic hero:
- We take a Mac (more precisely, we need OS X), take Xcode from the iOS SDK, take Objective-C or Swift, do a project, and at the output we get the most real, “native”, iOS-ovskiy application, which you can even upload with peace of mind in the App Store, and enjoy the
display of banners to the fact that our small development brings people joy. - We take at least a Mac, even a Windows machine, choose a framework that allows us to write mobile applications in more familiar languages ​​(JavaSctipt, C #). The framework will take care of how our code will run on the device: to ensure execution, our code will be linked to the code execution mechanism (runtime), whose tasks, among other things, include translating calls to the programming language used in the mobile platform API. The advantage of the approach is a certain independence from a specific mobile platform (with which only the runtime itself connects us), minus - to a lesser speed than the “native” application.
- Take
Notepad any text file editor, sculpt a web page, properly equip it, and at the output we get a web application that, in fact, will run in a full-screen browser window (like the real application on the platform - without the browser address bar), but it will work, of course, with the speed and responsiveness of an ordinary web page. First of all, this will be seen in the absence of a normal Internet connection, but you will agree that even this option is sometimes convenient. The web application, by the way, has the plus that in order for users to access it, the page does not need to be sent to the App Store, it’s enough to give people its URL and suggest adding “to the home screen” for themselves.
Apple's Path
The path of the
true Jedi labor iOS-developer lies in the plane of following the ideas of Apple. A fresh SDK, a fresh version of Xcode, Apple's documentation on Apple technologies, developer forums on Apple technologies - if you think about it, what else is needed to create a great application, apart from a bit of time? The benefits are obvious: the development is the closest to the platform and to Apple's ideology, using all the new products offered by Apple in the current (and future) iOS API, so that the constant study of the new brings more good than bad.
New Apple is voiced regularly. At the last conference for WWDC 2017 developers, a new SDK and a new version of the Xcode development environment were shown. The list of changes is quite extensive (especially in anticipation of the release of iOS 11):
')
Xcode
The text editor in Xcode was copied to Swift, making it safer and faster. Can this be felt? Yes! Syntax highlighting works (almost) instantly, opening and navigating the file now without noticeable delays, and error messages no longer overlap the source code. In beta, everything looks very nice, let's see what awaits us in the release!
Xcode adds support for Markdown. The markup can be used to document the code, and this functionality, at first glance, is cosmetic, makes it quite noticeable to read the code, especially someone else's:
( Source )The editor, by the way, learned how to highlight blocks of code, it is convenient when studying a large amount of code.
( Source )Another important feature of Xcode 9 was refactoring of the code in Swift, Objective-C, Objective-C ++, C. Refactoring allows you to rename classes, variables, and also split the methods into smaller ones.
( Source )Of the less prominent, but nonetheless useful features, you can name:
- New build system (by the way, written in Swift);
- GitHub support;
- UI debugger began to show UIViewController;
- Added more checks (for example, main thread API checker and undefined behavior tracking);
- Parallel running of tests on different devices and simulators, UI tests of several applications;
- "Wireless" debugging on multiple devices to test applications for iPad and iPhone.
Swift 4
This change stands alone. Anyone who has already experienced the feeling “in Swift 2 was, in Swift 3 was gone ?!” may feel deja vu, but now changes are expected, rather, for the better (however, I note in a low voice when it was not so, according to the authors then?)

So:
- Applications written in Swift 4 will be smaller in size.
- Swift 4 will get native support for encoding / decoding to / from JSON. Before Swift 4, I had to write a lot of code myself, or use third-party code generators. Now this code is generated by the compiler. Special thanks to!
- Returning to a convenient model for working with strings, which was implemented in Swift 2 and removed in Swift 3. Together with this change, the strings will better support Unicode (“so that your favorite applications show all your emoji correctly”), and work with them will speed up.
- Projects that use both Swift and Objective-C will build 40% faster due to improvements in Xcode 9 and its build system.
- Apple (as usual) promises simple migration to Swift 4, and simultaneous support for different code bases (3.2 and 4.0).
"Hybrid", "not quite native" application
To clarify: the term in the title, even in its essence is not very true. The applications that we get as a result are native in the sense that they run on the same iOS, on the same hardware as any other software for iOS, just the development process itself allows using not only the Apple technologies and programming languages. If a person can write, say, in JavaScript, and does not want to understand Swift, then Apple will not help him (except, of course, a good Swift tutorial), but write an option, say, an application in JavaScript, and then run it on iOS, as if it were written in Xcode (thus obtaining a kind of “hybrid” version) exists, and is quite in demand.
Ionic

Ionic is one of the most famous frameworks for cross-platform development. It is based on Apache Cordova, which provides access to various functions of the device, such as geolocation, push notifications, camera and others, and allows developers to create applications for iOS and Android with web technologies, such as HTML, CSS and JavaScript.
In addition to the framework, Ionic boasts a whole ecosystem that makes it easy for novice developers to learn and enter. Ionic Cloud provides developers with various tools for managing, deploying and scaling applications on Ionic. Ionic Creator is a visual editor that allows developers to quickly prototype and create mobile applications by drag & drop. Finally, there is Ionic View, a free application for iOS and Android, which allows developers to easily share their Ionic application with users, testers and customers without having to deploy an application in the application store of a specific mobile platform. Developers simply send users an invitation from the Ionic View application, and once it is accepted, the user can download and launch a specific application in his copy of the Ionic View - as if the application was installed on his phone from the application store.
Alas, there is also a fly in the ointment. Applications written using Ionic use WebView, as a result we get the most natural web application, with its usual (usually not the most impressive) speed. Due to this, it is difficult to consider it suitable for creating heavy applications, such as games, or programs with intensive use of graphics. Development with Ionic requires good knowledge of Angular, at least if you want to “squeeze” out of the framework as much as possible.
Phonegap / Cordova

PhoneGap was originally created by Nitobi. In 2011, Adobe acquires Nitobi and the brand PhoneGap. Adobe then hands over one of the versions of PhoneGap (calling it Cordova) to the Apache Foundation, keeping PhoneGap as the product itself. As a result, Cordova can be viewed as an engine under the hood of PhoneGap (as well as some other hybrid frameworks). PhoneGap, in turn, adds to the capabilities of Cordova its additional features.
PhoneGap is in many ways very similar to Ionic. It also gives developers the ability to create cross-platform applications using web technologies, and is also based on Apache Codova. However, PhoneGap is not tied to any particular Javascript framework, so developers have a greater choice on what and how they will build their applications. PhoneGap has a desktop application, a mobile application, and a cloud service called PhoneGap Build, which allows you to build and deploy an application.
Alas, like Ionic, PhoneGap uses WebView (which in iOS works rather slowly), so with the speed of applications created on the basis of this framework, things are not always brilliant.
Xamarin

Founded in 2011, Xamarin, which produces the Xamarin product family, after five years of its existence, was bought by Microsoft. Today, Xamarin products present a very interesting approach to the development of cross-platform mobile applications on the market: applications are written in C #, then Xamarin compiles it into a native application for iOS or for Android, while using Xomarin as its core technology than cross-platform and provided. The Xamarin developers say that the resulting applications use the native API of the platform for which the application is compiled, so that the behavior of the resulting application does not differ from the behavior of any other application on the same platform. Development, by the way, can be conducted using Visual Studio (which is not surprising).
Despite the fact that most of the project code can be used without changes on each of the supported mobile platforms, nevertheless, you need to write some snippets specifically for the version of the application for iOS and for Android.
React native

The React Native project was born on Facebook, and is based on React. Our JS-application is spinning on the engine built into iOS: it runs the code and performs all the manipulations with native OS widgets. React Native is comparable to Xamarin, while applications created using React Native are very similar to native iOS and Android applications (because they actually operate on native UI elements).
The React syntax is quite simple, which makes learning the framework easier, and the Standard UI component library in the React Native package contains many useful components, but the biggest difference between React Native and other JavaScript frameworks is called the ability to use code in Objective-C and Swift (more often for to improve performance or more subtle interaction with the mobile platform). In practice, this means that developers can use existing native libraries in their React Native applications.
Web clean web
The often underestimated opportunity to use a web page as a separate application is nevertheless at our services: if there are no special problems with communication, and the application has simple functionality (displaying a data table, or displaying a constantly updated list), then there is no reason not to use the good old web. viewing information from the server.
The difference between opening the same page in the browser will be in the design of the screen: the browser controls (including the address bar) will be hidden, and the page content will be displayed on the entire screen of the device. Out of inconvenience, of course, we are waiting for quite a long time to open such an “application” (which is related to the speed of the response of the remote web server), but for a number of applications this, I think, is not a problem at all.
Developing applications for mobile platforms has its own trick: at first you think that business is not worth the effort and time, then people start using your application, and using it, literally carrying it with you, and here you understand that it turned out to be deeper, and pulled you more than you could ever have imagined.
If you like mobile development just as we love it, I recommend to pay attention to the following reports
Mobius 2017 Moscow (yes, in November Mobius goes to Moscow, if you didn’t know yet):