Tuesday, 22 November 2022

mobile app

Mobile app development


– And how much has something changed for those developers who are not going to get into any machine learning, but are making some kind of typical application?

– iOS has its own changes for them. One of the obvious ones is very fast password filling, and so many developers with authorization in applications should support this. A whole session was allocated for this at WWDC. Or, for example, Drag and Drop – if the application supports the iPad and work with data, then most likely it makes sense to try it.

Another interesting innovation was Dynamic Type for third-party fonts (this is when a person chooses the font size that is convenient for him, and applications adjust). Third-party developers ignored this functionality (although there are many visually impaired people in the world), because they used third-party fonts, now the situation may change.

But if everything is clear with iOS, then this time there are a lot of innovations in Xcode. In my opinion, this is one of the biggest updates in recent years.

– And if in the case of iOS, some will only look at the novelties of the 11th version in a year, then Xcode should be updated by everyone right now, and everyone will feel the improvements?

– Yes. They greatly accelerated it, rewrote a lot of things from scratch. Right now I’m sitting in two different versions of Xcode at once, and, according to my feelings, the new one is much faster.

Also, many developers are glad that refactoring has appeared, this was not enough in Swift. If someone wanted to rename a function or class, or solve some more complex tasks, then they had to either use third-party tools like AppCode, or do it manually. Nobody likes routine work.

And the most interesting, in my opinion, was that now you can write your own extensions on Xcode, which will support additional actions with your code. And this immediately opens up scope for custom refactorings (like simplifying a large if-else into a ternary operator, if there is little code). Developers may now have fewer reasons to switch to AppCode.

– About AppCode, by the way, it is curious what is now in the community with its use. It is difficult to compete with the IDE from the main vendor – how does JetBrains manage to do this, and how exactly does it manage to attract developers?

– I myself worked with AppCode quite a bit, but I see that there is a caste of developers who use it. Usually these are advanced developers who lack some features in Xcode: complex custom scripts, or the same refactoring, or, interestingly, pull request reviews are built into AppCode (using Upsource), and in general version control is good is arranged, so you can check other people’s branches, other people’s PRs directly from the IDE.

Of course, many developers do not want to switch to new tools, because Apple has already made Xcode for them, it is free, advertised everywhere, and immediately supports betas. But, in my opinion, the ideal option is when you combine two instruments. It’s complicated, but, for example, you use Xcode when you need to test future betas, and AppCode when you check other people’s branches.

– Swift 4 is approaching. What are its technical changes, it’s easy to google, but I want to ask about something else: how does the community feel about it? Is he eager to move on as soon as possible, or, conversely, after a painful transition to the third, is he now “blowing on the water”?

— Well, the transition to 4.0 should be painless. Swift 3.2 appears, which is almost the same as the current Swift 3.1.1, and at the same time works with Swift 4.0. That is, now the famous problem should not arise when some third-party library written in Swift that you keep in the project does not support the latest version, and you do not know what to do – do not add for the author. In my opinion, the transition to Swift 4.0 will not take more than an hour or two.

So there are no particular concerns, but at the same time, the situation around the new Swift in the community is as follows: they simply hardly talk about it. Due to the fact that its changes are “under the hood”, imperceptible to those who use Swift. They are related to performance, to fixing bugs and the like. And if the developers talked about 3.0 in the key “everything will break”, then they simply don’t say anything about 4.0. It turns out the situation “either bad or nothing.”

– A year ago, Apple, encouraging everyone to actively use Swift, while itself almost never used it in production. What has changed with this in a year?

– A year ago, the situation was like this: a calculator was written in Swift in iOS, a WWDC application, and, if I’m not mistaken, one of their new frameworks – indeed, quite a bit. And now, for example, the updated App Store is written in Swift – it is clear that this is a rather gigantic thing, full of complex custom UI components, and, probably, surpassing many other Apple applications in complexity. And Xcode now has two Swift systems. Firstly, a new build system designed to speed up the assembly of the project, and secondly, the source editor – this one was not written from scratch, but ported from Swift Playgrounds for iPad. So, as you can see, Apple has made a lot of steps towards Swift over the past year.

– To the question that the source editor is ported from the iPad. The Swift Playgrounds app feels like a prank — “give kids a free first dose of Swift on a tablet so they can get on with it in earnest on a Mac.” And the words that something was dragged from there to the desktop Xcode sound like Apple took the iPad very seriously, putting it ahead of the desktop in some matters. Where is the truth?

Well, in this case, the iPad was more like a test device where they tested the new source editor, and when it worked well enough, they were able to port it to Xcode. The same new build system is not a basic, but an additional option, you can optionally build a project from the old one. But the source editor is already mature enough to be inserted as the only option.