In 2007, Steve Jobs introduced the very first iPhone to the world. Back then, they talked a lot about the possibilities of the new smartphone, but nobody said how these opportunities became tangible.
The iOS architecture was similar to MacOS, but the system was completely closed. At first, Jobs did not want any third-party developers to develop applications for iOS, and, therefore, he did not intend to open the SDK. Instead, he wanted developers to create web applications and provided them with the opportunity to create browser bookmarks on the home screen. We know this from the Jobs biography written by Walter Isaacson. Here’s the quote by Steve Almighty himself: “The fully functional Safari engine is already inside the iPhone. This way, you can create amazing Web 2.0 and Ajax applications that look and behave like native iPhone programs. And they are able to perfectly interact with its services: make calls, send emails, search for a location on Google Maps. And guess what: you do not need the SDK to do this!”
However, there’s always an answer. Some people have hacked the file system and began to write installers for native applications. It hasn’t taken long for them to start writing applications themselves.
Later on, the Apples’ board of directors convinced Jobs to legalize third-party applications. As a result, in March 2008, the iPhone SDK became available to everyone, and in July of the same year, they presented the App Store. This meant that Apple would distribute development products to users.
The App Store was the impetus for the evolution of the application development industry, but the problem was called Objective-C. The programming language for iOS was radically different from popular languages as JavaScript and Flash Action Script. Few people wanted to spend time learning the new syntax, because iOS devices still had a tiny market share, and most of them belonged to Symbian smartphones.
At that time, developers were into making games, and the development of applications was considered as purely “funny business” for specialists in related fields. It was possible to earn money from selling games, but there was still no demand for developing services and applications for business. In a nutshell, companies were not interested in developing applications for customers.
Here’s the bunch of why’s:
- first of all, applications were not suitable for serious tasks due to data security issues;
- businesses did not trust mobile technologies and no one knew how to use them for the benefit of the companies;
- there were limitations of smartphones in displaying, transmitting and receiving data;
Cross-platform issues
In 2008, the Android Market was born, and three years later – the Windows Mobile Store.
By that time, the mobile Internet became more accessible, and both security and integration solutions appeared in the SDK for various platforms. This was a huge step forward in the development of applications: from entertainment to the people, developers moved to solving business problems. But there was another problem ahead.
The rapid parallel development of iOS and Android created a bipolar system, and developers needed to support multiple platforms simultaneously. At the moment, there were only two cross-platform solutions available: Flash and the usual mobile browser. Moreover, in 2010, Apple abandoned the support for Adobe Flash technology in iOS.
The development of the simplest solutions for different platforms hit a brick wall of human, time and material resources. Although browser technologies were developed quite well, mobile web development was hampered by the poor performance of smartphones.
What’s next?
Do you remember the first line in the third paragraph of this very article? Again, there’s always a solution. I talk about Xamarin, Cordova, Phonegap – the libraries of components and frameworks for creating applications on Android and iOS based on browser technologies without programming languages.
With their help, a similarity of the mobile site is created, the platform code is superimposed on top, which translates calls from system to application and back.
These tools helped mobile applications developers to solve the problems of non-complicated applications with little functionality and enabled businesses to quickly test their presence on mobile platforms. Then it was necessary to look towards the native development because there were acute problems of performance, resource consumption, the responsiveness of cross-platform applications and “alien” design. But that’s the subject for another story.
Comments are closed.