Mobile App Development Transformation

In 2008, iOS App Store and Google Play Market were launched and their introduction heralded a new era of mobile. It’s been thirteen years since then and many things have changed – but have you ever thought about the state of mobile development back then?

We spoke to Alexey Shevchik (SoftTeco’s CEO) and Igor Sapyanik (Head of iOS) – the people behind the very first iOS applications developed by SoftTeco. In this interview, Alexey and Igor discuss the way the mobile development industry transformed over years and what we can expect from it in the future.

First things first – how did mobile development in SoftTeco begin?

Alexey: We started working on mobile development in SoftTeco in the late September of 2008 and it’s interesting to note that the company was launched a few months before that, in April 2008. Our mobile development story was very much like other “success stories” back then: we had a client who wanted to create a mobile application similar to existing ones and to earn money on it.

The app itself was not very complex – it was a game for the Apple iPhone platform (that’s how it was called at that time). If you are interested to learn more about the game, you can check it out here. 

The first public version of SDK was released in the summer and our team started the development process in autumn. We had almost no tools to work with, in terms of available libraries, frameworks, and engines. Because of that, we had to create many things from scratch. For example, we had to build a game engine from scratch by using C++ and we had to adjust it for launch on the Apple iPhone platform.

Development was challenging as well. Before SoftTeco got its very first Mac mini that was shipped from Canada, we were actively using the Hackintosh system on our PCs. Note that it didn’t work on all computers so there was a lot of guesswork. When I was using Hackintosh, for example, my system would completely ignore the temperature sensor (or it was simply unable to turn the cooler on) so I had to turn on the processors’ forced cooling.

Getting back to the game development, we had some really extensive plans. The company aimed for creating a Scoring Server – a server that would store all user’s games and would “recreate” the games based on the user’s activity. We successfully accomplished this – the model worked right on the server and we even have some of the debugging games saved till today. As for the game mechanics, there were spaceships that were supposed to move from point A of the map to point B. Note that all those ships had different features, no copypaste.

SoftTeco was fully responsible for working on the game equilibration: we created Excel tables with characteristics of spaceships and towers and used them for analyzing the chances of a user to pass a level. We also were responsible for the game design and for that, we had to master Photoshop.

What background knowledge did you have before starting to work on the app?

Alexey: At that time, I mostly worked with Erlang and wrote scripts on bash. So when we got our first project, we had to find a person who had experience working with iOS – that’s how Igor joined the team. 

When working on the app, I was responsible for the game engine and mechanics while Igor focused on the development itself: OpenGL graphics, menu, resources, sounds. And obviously, as the project developed, we were assembling more and more people to the project and were teaching them “on the go”. We were really lucky to have enthusiastic quick learners on the team!

Igor: Before joining SoftTeco, I spent four years working as a firmware developer in the sphere of the Semicon industry. The company was designing silicon wafers handling systems that were used by big microchip fabrication plants. While working there, I worked with Embedded C so it was really easy for me to understand Objective-C later on. A few months prior to joining SoftTeco, I explored iPhone SDK 2.0 Beta and even managed to write my own small game with a physical engine in conjunction with the accelerometer.  

Describe the mobile app development industry back then 

Alexey: In 2009-2010, the mobile development industry experienced technological hype. Every company wanted to have its own mobile app and everything was new to everyone. Developers were eagerly awaiting the releases of new OS versions since every new version offered some kind of innovation or significant improvements. Among such “breakthrough innovations” were the push feature and working in the background, for example. As well, developers were extremely happy to finally get the text copypaste feature in the iPhone SDK – before its release, it was impossible to highlight and copy the text from Safari and insert it in another application.

It’s also interesting how liberal Android used to be in terms of development restraints and how it became almost as strict as iOS. When it just started, Android allowed lots of access freedom, including endless background mode use or access to the SMS mailout from one’s number. However, it had a negative impact on the battery life of a device. Now the Android system is more balanced and in some ways even more strict than Apple in terms of access and permissions.

And what about Objective-C and transition to Swift? How did it go?

Alexey: I think Igor can answer this question in more detail. But in my opinion, strictly typed Swift brought a very strict architecture into iOS development and this is one of the biggest differences for me. Developers started using efficient testable architectures (MVP, MVVM, VIPER) to write apps on Swift and they now follow strict SOLID principles in their development process.

Igor: I think Swift became a natural step in the “adulting” process of iOS technology. At some point, developers started to realize that Objective-C had quite a few limitations. It was especially notable due to the high number of checks that we inserted in the code and this is always an indication of a strictly typed language. In Swift, such things come out of the box and this is the reason why Swift’s code is more concise and readable.

As the iOS development evolved, such Objective-C features as its compatibility with C/C++ started to fade. As well, the Objective-C runtime abilities that were considered highly efficient before (i.e. method swizzling) started to be perceived as a dangerous hack tool instead. In comparison, Swift is much safer and much faster due to its static method dispatch (dynamic dispatch in Objective-C).

The syntax of Swift is more traditional so it’s easier for a developer to switch to Swift from another language. With Objective-C, a developer would spend a minimum of a week to get used to its syntax. By the way, it’s really easy to read Kotlin after Swift which is especially useful when porting a feature from the Android code to the iOS platform.

Of course, the first Swift versions were far from perfect. In the SoftTeco team, the first developers to try Swift out were Eugene Karachynskyi and Mihail Kosyuhin. It was back in 2016 while the team worked on an electronic wallet application. The first Swift versions were so slow in the compilation that the same project on Objective-C would compile faster.

The biggest pain point for our clients was adding new features to their Swift projects. We had that Swift v2 project lying on a shelf for a year and then a client asked to change a single line of code in it. He was really annoyed to find out that it would take us one hour to change the code and two weeks to take the whole project to Swift 3 because Swift 2 apps were no longer accepted by the App Store.

Getting back to the transition from Objective-C to Swift, Apple took really good care of those transitions and made sure they were as smooth as possible. The connections between Swift and Objective-C were well thought out and documented. Luckily, SoftTeco never had to rewrite the existing Objective-C project to Swift. Instead, it happened step by step: new modules were written in Swift from the start and the old ones were rewritten or tweaked only if necessary.

Note that all these inconveniences are normal for any new language. And right now, all of them are fixed.

During our hiring process today, SoftTeco sees many iOS developers who know only Swift. As for Objective-C knowledge, we state it as “nice-to-have”. Either way, it’s not so hard to learn Objective-C on the support level. But in our work, a great emphasis is placed on one’s experience with system frameworks and not on the language that you use to work with them.

Describe the biggest challenges of mobile development back then and what changed today?

Alexey: One of the biggest challenges that immediately comes to my mind is crash debugging. If an app crashed, it was a big headache for a developer because the only way to understand what happened was only by a thorough analysis (and a bit of intuition and deduction). That was at the very beginning and crash reports for the clients appeared much later. 

I remember the first time we implemented a third-party custom crash report and it worked. We were so immensely happy to finally understand where exactly the app crashed. Today, Xcode Instruments provide many tools for debugging and performance tuning that are just brilliant.

Another big challenge was the addition of new libraries and frameworks. At that time, there were big and complex guidelines on how to add a library or assemble it for different architectures. Many third-party libraries were available in C++ or for macOS only. Now we have Cocoapods, Carthage, Swift package manager, and other options available.

And one more challenge that I remember – the distribution of the binary file to the client. We had a really hard time doing so via iTunes and certificate installation. I remember how happy the team was when Apple allowed Adhoc app distribution via third-party tools (like HockeyApp). And now, of course, all these issues are resolved and there is hardly a thing left to worry about.

Was there anything in the past that was better than today?

Alexey: It’s a bit unfair to compare “now and then”, in my opinion. Back then, everything was being developed at a lightning-fast speed, the “turbulence level” was really high, and the system features were updated quicker. Now we are approaching the “plateau” level when some things still get changed but not so fast. Yes, the systems still receive new resources and possibilities but they are not so revolutionary as they were years ago.

Igor: I’d like to add that some people prefer working in a state of “high turbulence and endless opportunities” while others like to work with a technology that’s already stable and consistent. So there really is no definite answer to the question.

What is your forecast for mobile app development in the future?

Alexey: It really won’t make much sense to draw any forecasts now. If we focus on the mobile development “right here and now” – native mobile development has left the startup market and has shifted to niche verticals. Native development these days is requested only by those companies that have long-term plans for the app and who need it to be complex and feature-rich.

As for cross-platform development, it will continue its growth and it already has quite a big market share. React Native, for example, was a big hit, apps that were written in it work quite well so I personally don’t see any issues with it. I’m waiting for the Flutter to reach its fullest potential though because it seems to be stuck for a while.

I also think that Xamarin has good chances to gain popularity because it’s honestly hard to compete against the whole Microsoft .NET ecosystem. One developer is enough to work on some simple tasks on the backend, frontend, and mobile so it’s the cheapest option of a full-stack + mobile package. Note though that Xamarin will soon become part of the .NET 6 – we’ve covered the news in detail here.

Igor: And maybe there will be a brand new Apple innovation that would skyrocket? We never know!