DEV Community: Artem Poluektov

Launching new mobile app in 2 months with Agile transformation

Artem Poluektov — Fri, 24 Mar 2023 12:01:09 +0000

I’m going to tell you a story of how my team launched iOS & Android app for ticketing service in just 2 months, performing the transition from Waterfall to Agile without a lot of pain. I’ll start by describing the initial point of the project, how software development processes worked before and will to highlight key activities which helped us to succeed. This article is not intended to replace Agile manifest or The Book of Scrum by Jeff Sutherland. Instead, I’ll tell you how we changed our work process to deliver product faster without hiring an army of Agile coaches & scrum masters. This article would also be useful for those of you, guys, who thought about starting your own home project. I’ll show you what is worth focusing on at the specific moment of time and what isn’t. So, let’s begin :)

How it all started

It all started about 8 years ago. I’d just joined a huge media company in Russia which had a lot of different products: few online newspapers, entertainment services, sports portal, etc. And we also had this ticketing service I’m telling you about. The main feature of the service was selling e-tickets for cinemas, theatres, sports events online providing users and ability to book the best seats with no need visiting cash deck in advance.

Fortunately, we already had desktop and mobile websites running. And the service was pretty successful. As always, with some limitations. Not going to bother you with numbers, will just say that mobile website didn’t perform as expected. The primary reasons for that were:

Outdated UI design
Usability issues
Inability to view a seat map

Sure, it was possible to fix first & second issues but providing a fully-functional seat map and making offline tickets storage definitely required a mobile app. You should ask here how are users purchasing tickets without viewing a seat map on the mobile website. And that’s a great question. Our colleagues from backend team developed an algorithm which automatically selected seats as close to center as possible. Sometimes it worked great, sometimes not, sometimes customer wanted to book seats on last “kissing” row and was unable to do so. But benefits of the apps comparing to websites is an excellent idea for another article, so, here I’ll just say we were pretty sure that we need to launch the app.

In addition to websites, we had an XML API for partners’ sites letting them get a list of places, events & schedules with an ability to purchase tickets in the pop-up window. Now you should understand the initial point of our project.

Minimum Valuable Product

As I mentioned above, we widely used Waterfall approach in our work. We had separated iOS, Android, design, QA, backend teams and an army of project managers. So, when my project manager first approached me with this exciting new project, I was more than happy to start my very first product in this company from scratch. But all my happiness was gone after the initial meeting. What happened? The primary purpose for this meeting was to estimate release date based on very few UI designs we had. We found out that

The UI design wasn't complete, a lot of screens were missing
Those UIs we got were to complex, featuring a lot of complex gestures & animations, being too hard for users to understand and use and very hard to implement
Technical requirements weren't even close to being complete also
Backend team was busy for the next few months

That’s why we found we can’t make estimations to put a resource reservation on mobile developers for this project. To be honest, we actually were unable to predict a release date. Sure, we could possibly say that it will take approximately 6 months. But when you have no idea on overall volume and complexity of such a huge app, your estimations would be pretty inaccurate. And that’s a pretty usual situation for Waterfall teams. To fix this, I proposed launching Minimum Valuable Product (MVP) first with our own UI design and a small number of critical features in the first release, leaving all the others for the next versions of our app. The idea was looking pretty fresh & exciting, we decided to give it a try.

Focus on what’s really important

There were a lot of features in technical requirements and those UI design screens we’d got. We clearly understood that we just can’t develop them all maintaining the highest possible quality. And here comes Agile!

We wrote down a list of all features and asked ourselves: “Which one is the most important? Without what features our app just wouldn’t work?”

And here is the list of the critical features defining for our product:

List of cinemas
List of movies
Schedule
Seat map
Making a purchase
Purchased tickets

That easy. Just 6 screens. We tried to reduce the number of screens as much as possible to make purchase process simpler & faster, finally, we were able to cut it to just 4 steps: pick up the cinema or movie, select the suitable time from a schedule screen, choose seats on a seat map and make a purchase. Our app just wouldn’t work without any of these features. No beautiful animations, no complex gestures, no custom controls. Instead, system-provided tabs-based navigation, standard UI controls with minimum customizations. We were focused on providing our customers with content instead of an interface. And that’s how we actually build a great user interface which received A+ score at WWDC UI design labs session.

We discussed a lot of other great ideas during our work with my team, for example, we were pretty sure that storing user’s credit card data for future purchases would significantly increase a conversion rate. But it will take a lot of development hours, PCI DSS certification process isn’t easy. Instead, we decided to use WebView for payments, the same WebView on our website. So, this is one of those many features that should be held on the backlog for future releases.

To estimate the overall amount of work to do and track our progress we created a screen map. It is a huge image file containing all the screens of our apps connected by arrows representing screen-to-screen transitions. Screen maps are a handy tool for building mobile apps and even desktop websites.

Focus on crucial features defining your product. And put all the others to a backlog for next releases. Remember, you’re providing your customers with content not interface.

Communication is the key

Now, when we got a screen map, we were able to understand what APIs we do need. But the backend team was extremely busy, and we had a bottleneck here. Fortunately, we were able to estimate the amount of work needs to be done and [miracle happened here] we arranged to get 4 weeks of backend developer’s time.

How did we work with other teams before? When you need something to be done by another team you should ask your project manager, he or she goes to that team’s manager bringing the task. It was a too long way for tasks when we had just 4 weeks. So, instead, we created a new small team solely for this project and put this our developers inside. We had our own project in JIRA, our own backlog and didn’t accept any incoming tasks from other projects to be completely focused on our app. Our team was consisted of:

Me as a Team Leader creating tasks, providing communication between team members and pushing forward all the development process
2 iOS developers
2 Android developers
Backend developer
Designer

Now when we had a team and knew essential features we need to develop, we needed to make sure that we’re all doing the right tasks. But what is the proper task? It’s the one which provides features to our customers in the shortest possible way. The excellent example of that approach is UI design. I asked our designer to create UIs as close to native as possible because it is familiar to users and easy to implement by developers. So, we made a short workshop for our designers telling them what standard UI controls & animations we have and how we can customize it. We launched “design review” process where we discussed each screen together inside my team: designer tried to make it look better and developers — easier to implement. We were able to develop and maintain this communication process inside our team, and it brought us to success. We’d done almost the same developing APIs: backend and mobile developers were looking at UI screens and writing an API protocol convenient to both sides.

Make your teammates communicate with each other discussing the best way to implement the task. That will help them deliver better solutions faster.

Listen your teammates

Another essential key to our success was letting our team making decisions independently without hours of meetings reducing communications chain. In the previous paragraph, I mentioned that in the process of app development you should focus on critical features trying to deliver them as soon as possible and only then move to another feature. Here I’ll show you a few examples of small features we’d made in the process on main features development. These weren’t planned but were so easy to implement so we decided to include them in our first release. And all of them dramatically improved user experience and conversion rate.

The first feature was offline search. We had a search field on our website, but it was full-text search providing all results across all categories (i.e., one search field for movies & places). We had this feature in our backlog for the second release, but my team came to me complaining that it takes a too long time to find a test entity in cinemas list. This actually slowed down all the development. We discussed this issue and found out that we already had a list of all cinemas in our app and now could easily add a system-provided search bar on top of the list. It took about 2 hours for each platform without any changes to the backend and dramatically improved the usability of the app.

The second feature again originates from my teammates’ ideas. Sometimes it took up to a minute for ticketing system to provide actual seat map. It gave a lot of pain to developers who tried to test what they’ve done. Depending on cinema, the ticketing system stopped selling tickets sometime before the movie start, or there could be no free seats left. And the user has to wait while seat map loading to get this information. We found a simple solution for that: to add a check on the backend and flag to API for each time in schedule whether or not it’s available for purchase. Price labels on schedule screen was another bright idea. Initially, we haven’t thought about that. But some guys preferred more affordable tickets on a different time, it was insight from real-life behavior. If the user can see the price on a schedule screen, he or she doesn’t have to wait while seat map is loading on pricy times and could go straight to cheaper tickets. By implementing these features, we not only improved usability but also reduced the number of requests to our backend. So, it was a double win.

Another quick win was rounded seats on a seat map. Initially, our designer drew square seat icons with rounded corners which looked pretty good. But someday one of my guys found a cinema with rounded rows on a seat map. It seemed to look bad, very bad. So, we tried to create some complex equations to calculate seat rotation angle based on the radius of row rounding. Eventually, I found that we could make our seats round instead of square and we don’t need to rotate round seat because it’s round.

Your team is a very important focus group for your product. They are actually the first users of new features. Listen to them, give them the freedom of making decisions and they will bring you a lot of bright ideas!

After the first release

We had a lot of features in our backlog for the next release and it was extremely hard to find out which of them we should implement first. We decided to start studying users’ behavior. The entire purpose of our app is to help customers purchasing a ticket. So, the primary goal of our second release was to provide us with insights on how do customers looking for tickets:

Do they start with a cinema or movie selection?
How much time do our customers spend on the specific screen?
Why does the user close the payment screen?

After we’d collected some data, we were able to prioritize our backlog. For example, trailers, featured movies and frequently-visited cinemas were selected for our third release. Mostly because these features had a small estimated development time and some positive effect on conversion rate. Of course, storing credit card data would impact conversion much more, but all three mentioned features were completed in a week while it took more than 2 months to get PCI DSS certification necessary for card data storage. I don’t say that you should only do smaller tasks. Instead, it’s always better to find a balance between quick wins and major tasks promising long-term benefits.

I would recommend studying user’s behavior from the very first releases to be sure your team going in the right direction. And adjust your backlog [prioritization] based on those insights you would get from the data.

Conclusion

Finally, we’d launched the app. After just 2 months. And it was extremely short timing comparing to other products. Yes, it wasn’t fully functional as stakeholders wanted it, but it was just the first step.

Our new approach wasn’t near close to Scrum, it was more like Kanban, which is great when you need to launch the new product in a short amount of time. And this transition from Waterfall wasn’t any pain, we actually enjoyed the new way of working together, impacting app we built and getting the new results on a weekly basis.

Thank you for reading!

iOS development for beginners. Part 3: preparing for the interview

Artem Poluektov — Fri, 24 Mar 2023 11:53:02 +0000

In the final part of this tutorial, I’m going to guide you on how to prepare for your first interview for a junior developer position. As I mentioned in this article, I attended hundreds of interviews over my career on both roles. I started my career of iOS developer about 10 years ago, for sure, requirements are a bit higher today, but if you would prepare well, you’ll make it. Few times I even hired guys with minimal experience when I had only middle-level positions. How did it happen? They proved that they’re smart and would get things done. Check this article to get to know what to do and what to expect.

The necessary knowledges

Before attending an interview, make sure that you’re ready. Below I would provide you with a short checklist of most important areas of usual discussion.

Swift language features

As I mentioned in the first part of this tutorial, Swift is #1 choice for iOS App Development. And you need to know how to use it. Here is a list of the most important things you should be able to write even on a paper:

Creating a variable, understanding let/var difference
Understanding how Optionals work, if let condition
Weak references, some basic memory management knowledge would be a good addition also
Working with arrays and dictionaries (create, count, insert, delete)
Working with strings (create, count symbols, add substring)
Creating your own structs, classes, and methods
If..else and switch..case conditions
For cycles

Xcode

Xcode provides you a very user-friendly interface, so, it’s easy to learn how to use it. You should be able to:

Create a new project and add a third-part dependency
Run your app on iOS simulator and on device
Debug your app (understand what’s wrong using console output)
Submit your app to the App Store

UIKit

UIKit framework is a core part of iOS SDK. It contains UI components and controls. You should be able to:

Create navigation model for your app (UINavigationController, UITabBarController, UISplitViewController)
Understand the difference between modal presentation of new ViewController and UINavigationController push/pop mechanics
Create a new ViewController both in code and in Storyboard Editor
Understand the difference between UITableViewController, UICollectionViewController and UIViewController
Understand reusable cells mechanics of UITableViewController and UICollectionViewController
Use Auto-Layout constraints to build a user interface
Use UIAppearance proxy to customize colors of your app (in code)

iOS SDK

iOS SDK consists of dozens of frameworks with thousands of methods. Nobody can know them all. And you don’t need it too. All you need is to get and experience using a few of them and know where to find documentation for others. Here’s a list of most commonly used frameworks:

Foundation (base layer of functionality, networking, data structures such as arrays, dictionaries, strings, etc.)
UIKit (user interface)
MapKit
CoreLocation (GPS & accessing user’s location)
CoreData (local database, I prefer Realm)
UserNotifications
LocalAuthentication (TouchID, FaceID)
GCD (multithreading) is also good to know, at least you should be familiar with async and asyncAfter, main and background queues, you’ll find more information in this article I recommend you to use some features of each of these frameworks in your home projects.

3rd part libraries

Sure, every team has its own list of libraries to use, but you should be able to discuss some most common you used in your pet projects. For your interview, I think, only Alamofire is necessary. Don’t forget to include all libraries you use into your CV, and be ready to explain your choice.

Building your CV

The first significant step is to pass the screening stage and get an appointment for the interview. On this stage recruiter or HR specialist evaluates your CV on being either appropriate or not for an open position they have. The well-prepared CV would help you to pass this stage successfully. The good CV contains this information in 1 (one) page:

Your name and your current location
Desired job title (usually it would be Junior iOS developer)
Your education, major fields of study and graduation status
Work experience

Company doesn’t need to know your home address, city or state would be well enough to understand whether or not you’re located in the same area as the company’s office. Job title is another good addition to make sure your CV would not get lost.

If you’re still a student, make sure to mention that and point that you would need a flexible schedule or part-time employment. Usually, you would get much more options after graduation, because the most of employers looking for full-time developers. However, working full-time with a flexible schedule is very common.

If you do have a work experience not relative to the desired job, there is no need to mention that in your CV. For example, if you developed and maintained a website for your university’s department, and you’re looking for an iOS developer job, it’s still would be a good addition to your CV. However, working as a barista at a coffee shop wouldn’t help you. What you really could do is stating that you’d been an Independent Developer and now have 2 apps published in the App Store.

In the work experience section you should also mention:

Your completed projects (with links to App Store)
Your technology stack

Provided list of completed apps would help you to show the employer that you have some experience, able to write code and getting the project to release. Having developed at least 2 different apps would definitely increase the number of interview invitations and also would positively affect your initial salary.

It’s also very important to provide a list of technologies you’re familiar with. Usually, it’s better to add only those which you had used in your apps because you would need to discuss your decisions on libraries usage. Here is an example of a technology stack description:

Swift
Xcode, App Store Connect
iOS SDK: UIKit, Foundation, CoreLocation, TouchID/FaceID, GCD
Libraries: Alamofire, Realm, SwiftyJSON

Don’t forget to do a research

Before sending a CV, make your research on your future employer.

Check the company’s website, App Store, Google Play profiles to get to know about products/projects they’re working on.
Ask yourself why do you want to work for this company.
Try finding other opened jobs to compare salary levels with other companies.
If the company is located in a different area, check the costs of living in that place.

After completing your research, you should understand your motivation of joining this company and the salary level which would be comfortable for you. Be ready to answer those questions on the interview. Many guys don’t have specific numbers on their mind when I’m asking them for it. So, they’re asking me to offer them something and then they would think about my offer. That’s not how things work.

Prepare your story

After evaluating your knowledge and completing your CV, you should prepare for the phone interview. It usually lasts for 10–15 minutes and is intended to check your background, previous projects, motivation. The on-site interview usually starts with the same discussion. To succeed in this step you need to prepare your story. Sometimes it could be useful even to write it down. The sample structure of introduction speech could be:

Education, why did you choose your school, profession
Why did you decide to become a developer
What have you done to begin your developer’s career
Completed projects

It’s important to show your motivation to work and willing to learn. Think about how you’d choose between two companies and highlight 3–5 things that most important for you. Don’t wait to be asked for that, it’s usually better to finish your story with that.
I’m usually looking for guys who are interested in:

Building amazing product
Developing his/her skills
Working with a great team
And not for people who:
Seeking a job closer to home
Want to get lunch compensation
Looking only for a bigger salary

You’ll make it!

It wouldn’t be easy. You may have to attend a dozen interviews before getting your first job offer. Remember to make your choice carefully. It’s usually better to choose between 2 offers instead of signing in the first one you would receive. Do not expect to win from the first shot. Continue trying. You’ll make it!

iOS development for beginners. Part 2: courses and tutorials

Artem Poluektov — Fri, 24 Mar 2023 11:42:11 +0000

In the first part of this tutorial, I’d made a brief review of the initial requirements and recent technology trends. In this part I would start with a review of two ready-made iOS Development courses and later would also provide you with list of useful resources to get in touch with popular libraries, frameworks, and some other resources widely used by developers. If you’d choose to go only for the ready-made course, be sure to check my list at the end of your study for some topics you could miss.

kodeco.com

As I stated in the first part, Ray’s website is a trendy place for the beginners. When I was an iOS developer, I used this website to learn to use new frameworks and new iOS features. The tutorials were easy enough for beginners and very straightforward. However, featured some architectural anti-patterns like writing tons of code in AppDelegate breaking Single-Responsibility principle.
Pros:

many tutorials covering almost every topic you would need
new articles every day or two
prepared a study paths
very detailed tutorials
for the very beginners

Cons:

most videos do not feature transcription, so you have to watch it in full
some video tutorials are cropped into too small parts
wide usage of architectural anti-patterns
paid subscription ($19.99 monthly / $179.88 for annual plan)

So, kodeco.com is a pretty good source for beginners and even for junior/middle developers exploring new technologies. However, there are so many other ways to begin.

CS193P by Stanford University

Paul Hegarty works at Stanford University. With the introduction of the first version of Swift in 2014, he started the development of this course. Stanford is one of the world’s top universities in Computer Science, so it features very high-quality mark. Latest version dated Spring 2021 features almost all you need to begin writing code.
Pros:

free
provided by the world-class university
covers almost every important topic on iOS development including architecture
very focused and straightforward

Cons:

features SwiftUI instead of UIKit
suitable for people familiar with programming
no text transcription

I would go for Stanford as the initial point of the study. It’s free, already approved on many students and provided by one of the world’s top universities. It was also recommended by Craig Federighi, Apple’s SVP on Software Engineering. And by the day you'll complete the course, SwiftUI would become a little [or may be much] more popular.
You’ll find more info here.

Useful resources

This useful resources list is not intended to replace or compete with professionally prepared courses above. Instead, I’m going to focus on real-world app development and introduce you with popular techniques, frameworks, and libraries.

Development language

As I briefly mentioned in the first part of this tutorial, Swift is definitely #1 choice for macOS & iOS app development. And there a lot of official documentation about it.

I would start with watching WWDC 2016 video “Getting started with Swift” for a brief explanation of language usage and features.
The official Swift guide would guide you from the very beginning to in-depth and modern features. You could check it anytime you need to find new ways of solving your tasks easier.

Interface Builder

The second important step is to get familiar with Interface Builder, the tool which would make your life hundred times easier :) And, I also recommend to use Auto Layout, the technology to build adaptive interfaces for all available devices.

You could find all available UI controls and best practices to build great UI in Apple’s Human Interface Guidelines.
Watch this video on how to use Auto Layout Techniques in Interface Builder.

Source control

Every team uses a source control system to keep source code safe from losing it due to technical failures, to be able to move between versions or releases and, of course, to make working together on one project easier. Almost every mobile team today uses Git.

Find out what is Git and how it works in this tutorial.

Xcode has a built-in menu to create commits, for pull/push actions. However, some developers prefer SourceTree app for a simpler, more powerful and straightforward interface. Also, sometimes Xcode is getting crazy and throwing some “unknown errors” when you’re trying to commit your code. SourceTree would save you in these situations. You could download this app here for FREE.

There are many online source code storages available free of charge. Most popular are GitHub and BitBucket. For many years GitHub provided only public repositories for free, so that anyone could see all of your code in uncompleted projects, but a few days ago they launched private repositories, so nobody could see your code until you want it. BitBucket also provides you with free private repos at no charge.

Dependency management

Don’t try to reinvent the wheel. If you need to develop a new feature, try to use existing solutions first. There are many frameworks and open-source libraries available for free. The best way to find a library is Google [Surprise :)], which would lead you to either GitHub or StackOverflow and then to GitHub. Here are a few tips on how to choose a library:

Check a number of stars on the library’s GitHub page. It’s usually safe to use one with 1000+ stars.
Check the latest release date. You don’t want to use an outdated framework. A new iOS releases every September, so the library should be updated for new version around this date.

Popular libraries

There are thousands of libraries available. However, only a few are really useful and popular.

Alamofire is number one choice for the client-server app. It makes working with network request extremely easy. Check their GitHub page for beginners guide. Moreover, they have 30K stars :)
KeychainAccess is a beautiful and easy-to-use wrapper on Apple’s Keychain framework to provide secure storage for sensitive data such as a user’s password.
iOS Charts is a powerful library for drawing almost every chart you’d need in UIKit.
Realm is a very fast and easy-to-use alternative to Apple’s Core Data to create an offline database on the device. Check my article on comparing both technologies.

Here you would find a very popular curated list of other great iOS libraries.

If you need help

Go to StackOverflow. It’s the primary resource for getting help on solving developers issues. Try searching first, sure, somebody already had the same problem as you, and he/she got an answer. If no, try to ask politely, and you would get your solution very fast.
Don’t worry, even Senior guys couldn’t know everything. They just know where to find the right solution in the shortest amount of time. So they’re using StackOverflow dozens of times every day.

Preparing for your very first interview

In the next part of this tutorial, I would guide you on preparing for your very first interview, provide you with a checklist of necessary pieces of knowledge and also supply you with some useful tips and tricks.

Continue to Part 3.

iOS development for beginners. Part 1: initial requirements and technology trends

Artem Poluektov — Fri, 24 Mar 2023 11:24:02 +0000

Software Engineer job is not only exciting but also compensates well these days. You’re creating amazing products, making people’s lives better and spend your entire day in a cozy warm office with a friendly community. Few of my friends asked me how I started my career as an iOS Developer and what are the first steps they should take if they want to. First, I’d sent them to kodeco.com [ex RayWenderlich.com]. Ray had many great tutorials a few years ago which I used to get in touch with some new frameworks and technologies. As we found later, recently he started charging his users for a paid subscription for access to most of the articles. So, I want to provide you with a free, alternative guide. In this part I would start with:

initial requirements,
guide you through the latest technology trends
give you some useful tips on how to make learning fun and productive

In the next part, I’ll provide you with a review of best available courses and give you some links to documentation/tutorials for the most popular technologies and frameworks we use in production environment. In the final part, I would help you with preparing for your very first job interview.

Technical requirements

You may have seen those monitors with black windows full of endless lines of text in movies. In real life, we don’t use the Terminal, Notepad or other text editing software for writing code. We have an Integrated Development Environment (IDE) for that. Writing an iOS code is only possible with Xcode provided by Apple.

Also, Xcode runs only on Macs with installed macOS. Of course, there are some alternative ways supplemented by enthusiasts. You could try to install macOS on your PC or laptop [it called Hackintosh], try running a virtual machine with Parallels, VirtualBox and other virtualization technologies. There’s no such thing as a free lunch. In return of using these workarounds, you’ll get low frame rate, a lot of freezes and crashes. It would bring you so much pain so you would drop the study eventually. So, I recommend you to get a Mac.

The new M-chips developed by Apple are extremely powerful, so even with a basic MacBook Air you would get a great performance. However, it's better to fit it with 16GB RAM, or even better with 24/32GB because Xcode would love use all the memory you have :) Here is a short list of possible options:

Mac mini with M2 chip and with custom configuration of 16GB memory for just $799 would be a cheapest possible option to start with
MacBook Air with M2 chip and custom configuration of 16GB memory for $1,399 is light and powerful option
16-inch MacBook Pro with M2 Pro chip for $2,499 would be most comfortable to work on

If money isn’t a problem for you, go for 16-inch MacBook Pro. Its high-performance, lightweight and gorgeous display makes it the best laptop to write code. It’s a de-facto industry standard for a lot of professional developers. However, if you’re tighter on a budget, you should start with Mac mini and your existing monitor. You could also try searching on eBay, but make sure to check everything is working fine before giving your money away. As an example, you could easily find 2018–2019 16-inch MacBook Pro for less than $1,000 there.

Most professional developers I know also prefer using one or two 27" monitors to work with more windows and keep the eyes safe. Apple's Studio Display is gorgeous but expensive option.

Also, you would need an iPhone. Although Xcode has a great built-in iOS Simulator, it still doesn’t support full list of features the real device has. iPad is suitable for development too. However, if you have neither of them, I would suggest purchasing an iPhone because it has a much bigger market share, therefore, more users and more apps. I wouldn’t recommend you going for anything older than iPhone X mostly because of possible performance issues. Sure, the latest iPhone is the best, but you still could run your apps smoothly even on SE.

BTW, if you’re new the Mac world, you could download latest macOS version from the Mac App Store for FREE [open Applications folder on your Mac], and you would find an Xcode there too, also available free of charge.

Apple Developer Program

Signing up to ADP is another must-have action on your way of becoming an iOS developer. However, you don’t have to pay for it from the beginning. For years Apple had two different levels of their program: Standard ($99) for publishing apps to the App Store and Enterprise ($299) for corporate app development to publish to the internal app distribution system without public access. Recently they announced a new Individual program suitable for beginners. It’s completely FREE. With this program, you would get access to all Apple-provided development resources and documentation, WWDC videos, and would also become able to launch your test apps on the physical device. You wouldn’t get access to TestFlight, a beta distribution system hosted by Apple, and iTunes Connect (which was recently renamed to App Store Connect), a web portal to submit your apps to the App Store and manage them later. When you’d need a publish your first app, you could easily upgrade your program to Standard level.

To sign up go to developer.apple.com.

Technology trends

Like any other industry, we, in iOS development, have a few "holy wars" on whether or not to use specific technology:

Native vs. cross-platform
Swift vs. Objective-C
Xcode vs. other IDEs
UIKit vs. SwiftUI
UIKit Storyboards or writing UI in code
Rx (RxSwift, ReactiveCocoa) vs. Combine

I’ll provide some initial points and my opinion on those topics below.

The idea of writing code once and launching it on both iOS and Android [and maybe even on Windows Phone] sounds pretty exciting. However, in real life, it doesn’t look so bright & shiny. There were four significant attempts to solve this problem: PhoneGap, Xamarin (from Microsoft), ReactNative (from Facebook) and Flutter (from Google).

PhoneGap was based on WebViews contained HTML and JavaScript. The primary issue was poor performance and usability: UI controls and animations don’t feel anywhere close to native for the user. Xamarin has chosen a different way. They tried to translate C# code you’re writing to native code. Again, they’d got poor performance, lower usability and enormously long delays supporting new features. Being a popular framework for Web development, React tried to conquer mobile apps with ReactNative extension. You need to write JavaScript code, which later compiles to two native apps: one for iOS, one for Android. JS is a very popular technology these days, and there are a lot of JS developers on the market. So, we, the native developers, were a little bit scared of losing our jobs. Hopefully, even with Facebook support, ReactNative became another great failure. It features the same problems as its predecessors: poor performance, a lot of bugs/crashes, usability issues and, as always, you still need to write some native code to get access to system features or lower level hardware. AirBnb had recently published a fantastic article of their experience with ReactNative [spoiler: they’re sunsetting it]. You’ll find more details here. Both these technologies are almost dead right now. Flutter is the same idea from Google. Once again, it's good if you need to build quick prototype, but not suitable for bigger projects focused on great user experience and stability. The main reason for cross-platform technologies failures, in my opinion, is the need to support platform-specific changes and features. Every year Apple and Google release new versions of their Operating Systems full of new functions and SDK changes. With native development, you have access to beta versions and could prepare your app for upcoming changes. With any cross-platform technology, you have to wait until the developer this technology would release an update. Usually, it takes months. As for market-specific reasons, I would estimate that less than 1 of 20 companies chose to go cross-platform. So, the market for native developers is much bigger, and that’s great for you!

There are 2 main programming languages you could use to develop iOS apps: Objective-C and Swift. When I started my career [iOS 3.x times], Obj-C was the only option. Not going more in-depth into details, would point that Obj-C is based on C language which is pretty old these days. In 2014 Apple released a new modern language — Swift and they want you to use it. My team started the transition to Swift right after its first release, and we’d got many benefits: it’s simpler, safer, faster and more expressive language. It’s also much easier to learn and understand. From my point of expertise, I would estimate that Swift adoption was very successful: every new project today starts with pure Swift and the most of existing projects either already completed transition or at 80-95% of doing so. I don’t know any single developer who would be willing to write Objective-C code, so it’s incredibly challenging to find new developers for these companies which stuck with Obj-C. However, language is just a tool, and if you’re familiar with Swift and iOS SDK, you should be able to support and bug fix old Obj-C code. SDK knowledge is much more critical in this case. So, if you’re starting your way of becoming an iOS developer, go for Swift.

There are not so many alternative IDEs to Xcode. Xcode is doing a pretty great job these days. My teammates from Android community, actually, found that it’s doing better than Android studio :) The only alternative IDE that worth looking at is App Code, but you would have to pay for it, and you’d still have to use Interface Builder built-in in the Xcode. I use Xcode. It’s Apple-provided so you would get all the latest features and updates right after release.

SwiftUI is a new modern UI framework from Apple. During first releases it missed a lot of required functions easily available in UIKit, so not many teams decided to use it in their production environment. And like any other Apple's frameworks it misses backward compatibility. Starting from iOS 15 SwiftUI had finally got most of required features and components. So it could be used in new projects. But it's still too early to use it in existing apps if you have to support older versions of iOS. That's why I would start learning UIKit first.

Another hot discussion we had in the iOS community is whether or not use Storyboards. It’s UIKit's tool to create app’s user interface without in graphical editor without [almost] any line of code. With iOS 2.0 Apple introduced an iOS Interface Builder which allowed to create a single screen of the app. You could find the names NIB or XIB. It’s the name for a file containing user interface. XIB is the latest version. A few years later they introduced Storyboards, the way not only to build a single screen, but also to create transitions between screens, or making navigation. The main issues with Storyboards are lack of ability to reuse components [you still have to write code for that] and merge conflicts happening when more than one developer is trying to make changes in a single file at the same time. Also, you could get some performance issues while trying to open Storyboards containing many screens. Apple’s solution for that is Storyboard References, the way to separate one huge file into few smaller. So, it's ok to use Storyboards while learning UIKit but it's better to write UI in code in bigger projects.

Rx [Reactive eXtensions] is the technology which implements reactive programming paradigm. In a few words, it’s an alternative way to organize data flow in a multi-threading environment. While RxJava quickly became extremely popular in the Android community, a very low number of iOS teams widely adopted RxSwift/ReactiveCocoa. I see two main reasons for this. The first is that Apple’s GCD is helping a lot working with multiple threads, while Android’s AsyncTasks were not so useful. The second is that it affects your entire project so deep, so you need to rethink core architecture and code style completely. It would also raise the bar for newcomers: due to the low adoption of this technology in the iOS community there are not so many experts in it, so you’ll have to hire and teach new guys. It’s also important to notice that with the release of Kotlin’s coroutines RxJava started losing its positions within the Android community. I think that you shouldn’t worry about Rx and could skip this technology. Lately Apple introduced own reactive framework - Combine. However it doesn't seem to be widely popular due to completely different approach comparing to normal development practice.

Let’s summarize all the above:

Go for Native. It’s in very high demand these days
Start with Swift, it’s the future
Use Xcode for your first steps
Learn UIKit first
Storyboards would save you much time
You don’t need to think about Rx at the beginning

Build your portfolio from the very beginning

Most of the tutorials would teach you how to use a new technology or framework. Unfortunately, that’s not enough to succeed in the interview. People want to see not just your knowledge, but also the results you’d got. The best way to do so is to write a real iOS app or two. That would also help you to get more practice making your knowledge deeper and yourself — more valuable candidate. Don’t try to make another Facebook or Instagram, they have thousands of developers working on their site. What you really could do is create a simple and beautiful app which would make people’s lives better. Here are some examples:

Weather app
Shopping list
Expenses tracker
Time tracker

Sure, you may continue this list. So, the key is taking one idea and making it real. First of all, you’d need a UI design. Don’t try to make it complete and final from the beginning. Try drawing some screens on paper, browse the App Store and iOS built-in apps to study your competitors. Pick up the most exciting ideas and focus on what’s really important. You could learn more about how I’ve done that in this article. Then find out what technologies you need to use to complete your app. For example, for Weather app you would need to learn:

Swift as a programming language,
Apple’s UIKit to create a user interface for your app,
Alamofire to get a forecast from the remote server,
How to work with JSON and parse data into objects,
CoreLocation to get user’s current coordinates and show appropriate forecast inside your app,
CoreData or Realm to make your forecasts available offline.

Some part of this list would be the same for any other app of your choice. Sure, some technologies would be an app-specific. If you have enough time and want to learn more in-depth, pick up the second idea and create another app. It would help you with your interviews, not only to pass it but also to get yourself a higher compensation level.

Remember:

Pick up an idea
Create a UI prototype (on a paper, or take screenshots of apps you like)
Focus only on important features
Move with smaller steps to your own very first app

Tip: if you’d choose to create a weather app, check the AccuWeather APIs, they provide some weather data for free :)

What we’d got here

After reading this first part of my tutorial, you should have:

Mac with the latest version of macOS installed
Xcode
iPhone
Apple Developer Account
Higher-level understanding of recent technology trends
A bright idea of your very first iOS App and some UI prototypes for that

In the second part of this tutorial I’m going to review ready-made courses and provide you with useful frameworks and libraries.

Continue to part 2

Making interviews great again

Artem Poluektov — Fri, 24 Mar 2023 09:47:04 +0000

Bob Vulfov

@bobvulfov

[job interview]
INTERVIEWER: before we start can i get u anything? water or—
ME: id like a job offer
I: um
M: u said "anything"
I: well darn

15:30 PM - 22 Apr 2015

So, you need to hire some more developers? Moreover, you want to make it quick, productive and fun? Don’t worry, it’s easy, and I’ll show you the right way.

During my professional career, I attended more than 100 interviews, interviewed hundreds of iOS & Android developers and hired about 50 of them. In this article, I’ll tell you how we changed our hiring process to make it comfortable and productive for both sides. I’m going to describe how I interviewed mobile developers but the same ideas could and should be applied to different roles.

CV screening

Screening is the very first step in the hiring process usually done by HR or recruitment specialist. The main tricky thing for HR is to find the right skills and measure the candidate’s level based on CV. So, we [the developers] made a small checklist of what we’re looking for:

Years of work experience
Number of apps released
Technology Stack

As we’re not hiring junior developers, we expect the candidate to have at least 1–2 years of experience in mobile development. The only exception of this rule would be a guy switching from other technologies, in this case, we would expect at least 1 year of experience. For the number of apps, it could be either working on one big popular app or a few smaller apps. We also supplied our HRs with our technology stack, for example, we’re looking Android developers with Java or Kotlin knowledge, not Xamarin or ReactNative. Being familiar with RxJava or tests would add you some points. The idea of this activity is to help our HRs to filter hundreds of CVs they’re reading.

If HR finds CV to be fitting our position, he/she sends it to appropriate Telegram channel waiting for our developers to approve the CV. We don’t do polls or votes. Somebody sends “+” to the chat, and that’s enough. Trust me, sometimes we’re having hot discussions. Timing is the most important thing here. We’re trying to make a decision as fast as possible and either schedule a technical interview or say no.

Phone interview

We actually do not make any kind of interview over the phone. The main goal of the call is to make the candidate interested in attending the real interview and, of course, arrange a meeting. We’re working very closely with our HRs providing them with a lot of information about our technology stack and current projects. It happened to me many times over the first contact with a new company when I asked HR about team size, future plans, upcoming projects or the number of opened developers’ positions and they were unable to answer me sending me to interview with their colleagues. That’s not what I expect as a candidate. Let me know your company better, help me with initial research. I had an amazing experience talking to London-based recruiter earlier this month: he had so deep understanding of company’s current situation, products, issues and roadmap. And he was not even in-house recruiter, he’d worked for outsource agency. He also provided me with a lot of useful information about the areas I should focus on the interview. And that was really helpful. We want our HRs to do so, that’s why they:

aware of our technology stack and have some high-level insights from the technical roadmap, for example, Java to Kotlin transition
briefly describe future plans for our project to the candidate
kindly ask the candidate to attend a technical interview
describe our interview process to candidate

The last thing is crucial because we want the candidate to feel comfortable during the interview, so, he or she should have some expectations before the meeting.

Technical interview

The primary purpose of this stage is to measure the candidate’s level. There are so many different ways to do so: some companies send homework to check the code, some ask you about almost every algorithm from university class during 5 hours long session, some attack you with hundreds of low-level technical questions, while others try to set up a series of endless meetings with different developers they have. In my opinion, this is an unnecessary waste of time. You can’t be sure that candidate is making homework him- or herself without any help from the side. Usually, developers don’t use all these sorting algorithms in real life. Nobody can keep in their head all the functions from iOS SDK. What is truly important for me is that candidate is smart and gets things done. I found this great idea in Joel Spolsky’s book. How to find out that candidate is smart and would help you bringing your project to launch? First is education, of course. It just has to be. More important is to discuss a candidate’s career and achievements. What he or she did, maybe he/she found an easy way to solve a complex issue in a short amount of time or proposed an entirely new approach to improve product quality. That’s how we’re finding out that candidate is more focused on getting results instead of just writing great code.

It’s great when the candidate drives the interview, when he/she has a prepared route through his/her career pointing most exciting moments. Sure, sometimes interviewers need to turn the discussion a little bit into a right direction by asking suggestive questions. That’s why we usually send one experienced guy with strong soft-skills and one junior or middle guy who’s still learning that.

We usually start the interview with a friendly conversation about the candidate’s previous experience. Sometimes it may take up to an hour. Instead of asking prepared questions we discuss large topics like technology stack, why do they choose the specific library, what architecture they used and why, what are the pros and cons of some framework. Finding out how the candidate is thinking is another primary goal of this meeting. Usually, we’re fortunate enough to turn our conversation into talking about data structures, maybe some performance optimizations made in candidate’s past projects. In this topic, we usually ask about array/hashmap insertion/searching complexity, hash functions and collisions in hashmaps. Very few guys were familiar with cycle buffer, the way to maintain constant insertion time into the first or last indexes of the array.

From such talks, we not only understand the candidate’s level but also his/her ability making the right decisions which is much more important than specific SDK knowledge. You could quickly learn how to use new technology but learning to learn or to make technical decisions definitely would take much time. Giving a chance to a smart guy with a proven track record but the slightly different technical stack would benefit your product much more in long-term than hiring the senior developer who is just writing good code. Leaving candidate’s CV behind the meeting is essential for a great conversation: we’re reading it before and not during the interview. You have a live person in front of you able to tell much more than some papers.

During the interview, we also discuss the technologies we use, the solutions we made, our development process. All that very important to let candidate feel the spirit of our team. Eventually, our goal is not only to measure candidate’s level but also “sell” him/her our company. So, we’re doing our best to create a comfortable feeling. You know, competition is extremely hard for good guys. We usually send 2 our developers to technical interview session to reduce subjective judgments. At the end of the meeting, they should fill the “knowledge map”. That’s our another invention. There are 2 parts in this table: technical and soft (or personal) skills. I’ll give you a sneak peek for that table for Android interview. Also, we have almost the same one for iOS just with different tech skills.

Technical skills

Java
Kotlin
Android SDK, popular frameworks
Architecture, patterns
CI/CD, tests
Task or algorithms

Soft skills

Communication
Leadership
Problem-solving
Learning
Fitting our team

Of course, we have a grading scale for these skills:

Technical skills
0 - doesn't have experience
1 - fragmented
2 - strong base, enough to work on our project
3 - above average
4 - senior
5 - above interviewer

Soft skills
1 - weak
2 - medium
3 - strong

At the end of the meeting, interviewers are filling up this table independently and getting average for each skill. While they’re doing this, we have our HR ready to take the candidate to small office tour and give him/her a souvenir with company’s brand. Even if we wouldn’t hire this guy right now, we want to leave a positive image of our company. However, if he/she is meeting out requirements, after the tour I’m coming for the final part. We’re doing this to reduce the number of meetings and cut waiting time. Making decision faster really helps us to compete with other companies.

Personal interview

The primary goal of this part is to get to know each other better, find out what kind of person the candidate is and understand what his/her motivation is. Last is extremely important for us. I’m looking for guys who would like to build a great product improving people’s lives, who enjoys experimenting with new technologies and who has a passion for problem-solving. Will this person be a great addition to our team, our culture or this is another toxic guy interested only in salary increase trying to sneak into our company. I usually start introducing my self, briefly describing my achievements and then expect the candidate to do the same. I don’t need to ask any deep technical questions. My colleagues already did that. So, we’re having a nice friendly conversation about our lives. There are many areas to discuss, but I usually have a few general topics:

How will you choose your next place to work? What is important for you?
How will you spend your typical day?
What are you going to do this evening/weekend?
What are your favorite hobbies?
Do you have any vacation plans?
[And sometimes even] what’s your favorite drink?

From all these answers I’m able to compose an image of this guy. I’m not looking for specific answers. Here diversity is the key to success. Everyone in my team has different experience, character, and hobby but together we’re making a solid high-performance team capable of solving any task or issue. So, I’m mostly looking for a great addition to our team than a specific combination of different qualities.

Another useful thing is how we’re telling our decision. In other companies, candidate leaves office, interviewers are taking a break for a few days to make their decision and after a week or so would send an email with either job offer or standard polite NO. However, we thought, is it so necessary to take a break? We can and, for sure, would lose a great guy due to high competition with other employers. That’s why I always have pre-printed job offer ready for the final stage. And if things are going the right way, I only need to fill in an appropriate salary and sign it. I already know the candidate’s level, I just had a nice talk to this guy, why should I wait? That’s what bribes the candidate. Being honest and transparent, like they expect you to do in the everyday working process.

Saying NO the right way

If the things aren’t going the right direction, either candidate is too junior or his/her soft skills is not enough to join our team, providing feedback is very important. This guy could not be a good fit for this position now, but later he/she would improve the level, would learn to use new technologies and may just become a better person. That’s why we’re trying to be honest and transparent maintaining positive employer image. If I know the exact reasons why we can’t hire right now, I’ll highlight them right after the interview, I’ll try to give useful recommendations on how to improve some things, to show areas of possible improvement and good candidate would come back later and tell his/her friends a lot of good things about our company. The market is too small these days. Sometimes I can’t say anything and need to discuss this case with my colleagues. In this situation, it’s important to mark the date when you’re going to provide feedback in written form. Again, we’re not using standard replies. We’re providing the exact reasons with recommendations on how to improve it and even some useful links to books or articles.

Why doing all this?

We’d made a dramatic improvement to our interview process, and we’d got great results. We were able to hire the best guys from the open market and even some guys on recommendations. Maintaining a positive employer image would increase incoming candidates flow a lot. People would know that you have a friendly and helpful culture in your company. Moreover, they would value it, for sure.

Mobile database optimization: Realm vs. SQLite

Artem Poluektov — Sun, 19 Mar 2023 14:13:38 +0000

In this story, I’m going to tell you how we developed a structured approach to solving complex technical issue and successfully improved our app’s performance up to 30 times.

We started the development of a new enterprise app with gathering technical requirements. Initially, we found out that our app should include those primary features:

Reports containing charts
A simple task tracking system
List of all company’s employees

All these data should also be available for offline use. Sounds not so hard, right? We thought so. We picked up our initial technology stack basing on JSON for client-server interactions and SQLite for offline data storage on a mobile device. On iOS, we used MagicalRecord, a CoreData wrapper, very popular few years ago. Today it would definitely be a wrong choice because it’s written in Objective-C and hadn’t got any updates over the last 3 years. However, in 2014 it was free, open-source and had 10K+ stars on GitHub, but the main reason was lack of any alternatives. On Android, we decided to use ORMLite for the very same reasons.

Everything was going fine in the early stages of the development process. We had some demo reports and a few dozens of employees on our development server. However, we’d got serious performance issues right after selling our product to the first customer. Our colleagues from the backend team imported a part of the client’s production database to our test environment. And we found out that our app is not ready to operate with a list of 200K employees. It took between 5 to 10 minutes to download the full list, scrolling performance was poor and search just didn’t work at all. That’s not what our end-users expected. Another issue was reports. Some of them contained charts with millions of points, so we got the same issues: slow downloading and poor performance on both platforms.

We tried to make some hotfixes, introducing pagination to client-server requests and batch writing to the local database, but we were unable to increase performance high enough. Lucky for us, our sales department signed 6-months long contract with the client, and the first part was updating some internal systems, so we’d got a month or two to fix our issues. We understood that we needed to perform full research of what’s going on wrong instead of writing chaotic bug fixes. Below I’m going to tell you about our approach in details.

The research

We started with optimization of employees list performance. After few failed attempts of fast bug fixing, we decided to divide the process of downloading employees list and showing them in UI into smaller steps and measure a duration of each step to find out what needs to be fixed.

Finally, we found that waiting for a server response (30s) and writing to the local database (5–10m) is two longest parts of the entire process, while other parts took just a few hundreds of milliseconds, therefore didn’t require our attention.

Server response

Before any optimizations, we had a single request to download the full list of employees. This approach was chosen intentionally because any single part of this list doesn’t carry any value for end-user. Nobody wants to see just employees with last names starting with letter A. Our users need a full list to access all contacts and perform an offline search.

We also had a favorite contacts feature with sync between user’s devices through our server. First of all, we moved favorite data to separate request and separate table in our local database. That didn’t give us huge performance increase, but let us enable in-memory storage of full employees list on the server side.

The final and most important part of response time optimization was introduction of delta-updates. As I stated above, we stored a full list of employees in-memory on server side. It reduced response time from ~30s to just 1–2 seconds, we were unable to reduce it anymore due to network delay. After discussing our solution with backend and sales teams, we also found out that employees list usually could be updated just once a day, there is no need for more frequent updates. So, to reduce a load on server side and speed up database writing on a mobile client we introduced delta-updates. Right after the first install our app downloads full list, but the next day it asks the server for just a small delta-update providing a version (timestamp) of the latest data app has.

Local database optimization

Delta-updates dramatically reduced employees list update time. However, we still had two issues:

Initial load was too slow due to SQLite writing speed
Apply few delta-updates (for example, after 2 weeks inactivity) also took much time due to the exact same reason

After batch writing didn’t increase performance, we decided to try different approach. We had a hypothesis that either SQLite or MagicalRecord was a bottleneck in our case. So, we proposed 2 possible solutions:

Switching the ORM
Switching SQLite with other DB

We didn’t find any replacement to MagicalRecord, so decided to use CoreData. As SQLite replacement we used Realm. Then we developed a synthetic test to measure writing performance of 200K entities. Results were almost the same. That’s why we also decided to include MagicalRecord to our test. We were surprised finding that all 3 tests were running for almost the same amount of time. Here we finally found our issue: creating relations between entities. In our synthetic test, we implemented writing to a single table, while in the production app we had 2 tables with relations. See image below:

Each employee had approximately 3 contacts: email, mobile phone, and work phone. So, we needed to write 200K employees to one table, 600K contacts to another and also create 600K relations between these two tables.

We updated our synthetic test and found that CoreData (or SQLite itself) is working with relations extremely slow. We were able to achieve up to 30x performance increase switching from CoreData to Realm. The primary reason for that is Realm’s no-SQL nature. You could find more technical details and explanations here. See the chart below:

Search performance

So, we were able to achieve great downloading performance decreasing initial load time from a few minutes to just 15 seconds. Scrolling was now smooth too. However, we still were unhappy with search performance. In some cases, it took minutes to reveal all search results. Below I’m going to explain to you why it was so complicated.

Here is the list of all search fields in 2 different tables:

It was required to develop full-text search over first name, middle name, last name, any combination of those three, position, company, division, email and phone. Remember, we had 200K employees and almost 600K contacts (both emails and phones) in our database. We had to run 8 search queries for each user’s input. It took too much time to process a final response from the database. Another complication was wide usage of Cyrillic characters. All names, positions, companies, and divisions were Cyrillic-only. While emails were a mix of Latin characters and digits, and phones were digits-only. I would skip deeper details on phone extensions.

First, we decided to limit a minimal search query to 3 symbols. Then, we performed some basic analysis of those symbols. If there were Latin characters, it definitely was an email address. So, instead of running 8 queries we were able to run just one. We did the same with phone numbers. However, some emails contained digits, that’s why we run 2 queries over emails and phones. With this optimization, we cut the number of search queries twice.

We still needed to increase name, position, division and company title search performance. After another research over the latest publications over different websites, we found that our main issue is case insensitive search. It worked very fast for Latin-only characters and 8–12 times slowly for all others due to checks for similar characters like a, à, á, â, ä, ã, æ, å, ā. There are 9 different A letters! And the same for many others. So, we had to turn off case insensitive search and create lowercase fields in our tables. That gave us 8 to 12 times performance increase depending on a specific word.

We also removed some cases of first, middle and last name search combinations using our knowledge of Russian writing specifics. Users usually use 1 of 7 combinations:

First
Last
First Last
Last First
First Middle
First Middle Last
Last First Middle

Nobody in Russia would search for Middle First or Middle Last combination. That knowledge let us remove, for example, search of single word entry over Middle name field. With this, final update, we achieved another 1.5–2 times performance increase.

We created a synthetic test to measure search performance. It contained ~ 100 different search queries, mostly focused on name and position search, like it is in real-life usage. And here are our results:

After applying all new search optimization algorithms we increased search performance 23 times!

Reports workaround

After succeeding with employees list performance improvements, we started a full transition to Realm. Eventually, we found that some reports are still working very slow. We implemented the same storage model as on our server side: storing each report in 4-5 different tables. We had 5 different report types, and each had different data structure. For example, one of the reports consisted of chapters, chapters contained charts, charts contained series, and series contained points. We created 5 tables to store all these data. Some charts contained millions of points, it was really huge amount of data.

After making a time measurement research, we found that our bottleneck in this case was the database, again. However, we had already switched to Realm, which gave us some performance increase, and we, actually, didn’t have other databases to switch to. Simplest solution we found was sending mapped data from server directly to UI and writing to DB in background thread for future usages. It should work very fast, but would create architectural hell. Think about it, you would need to map DB’s managed objects to some plain objects every time you try to pull data from database. Creating some protocols (interfaces) wasn’t considerable option due to managed objects behavior: it could change or even be deleted in every moment, and we need to observe that. However, plain objects would always stay the same.

Finally, we found that if we could use plain objects in our UI, we don’t need managed objects at all. We could store raw JSON data directly in database and map it on demand. We still had some fields on reports table, like title, update date, author, etc., but report’s body didn’t contain any relations to other parts of database, that’s why could be stored as raw JSON. This tweak gave us up to 300 (yes, three hundred) times performance increase and amazing user experience.

Lessons learned

We spent almost 3 weeks trying to optimize CoreData queries, and we failed that. However, we were able to stop these attempts and found a better solution. Switching database was extremely hard process. It took about 2 months to complete this task, and I’m still not sure if it’s possible to complete this faster. In our iOS app we used VIPER architecture and implemented Service-Oriented Approach, but due to CoreData’s nature (we widely used NSFetchedResultsController to improve performance) we still had parts of our service (database) layer in Interactors. However, in terms of VIPER, Interactor shouldn’t know anything about specific database adaptor we use, which required us to drop NSFetchedResultsController usage. What we cannot afford due to performance. Yes, it’s a cycle reference :) So, we decided to leave part of our service layer in Interactors replacing NSFetchedResultsController with Realm notifications mechanics. It was the hardest part, we hadn’t change database entities at all, just replaced NSManagedObject inheritance with RealmObject.

Both my iOS and Android teams really enjoyed working with Realm. It’s working fast, easy-to-learn and easy-to use. It requires much less code, especially on Android comparing to old ORMLite and even new Room.

What we learned:

Before making any optimization, be sure that you know the specific place needs to be improved
Don’t try to squeeze every last bit of performance if you’re not sure what to do
Make experiments and try new technologies
Always look for suitable solution for your specific task

Maybe Realm wouldn’t work for your specific task such well as it worked for us, but before making your choice, try to run some performance tests on your tasks. Costs of switching local database would always be bigger than the costs of running a few tests.

The bottom line

Realm would be usually faster, much faster than CoreData due to its no-SQL nature. The main advantage is extremely fast management of relations between tables. Also, it’s much easier to use comparing to existing SQL ORMs on both iOS and Android platforms. However, you could experience some bugs and lack of documentation in deeper areas. Personally, I would go for Realm on my next app.

iOS PDFKit: creating PDF document in Swift, inserting/deleting pages

Artem Poluektov — Sun, 19 Mar 2023 13:44:24 +0000

This is the third article about Apple’s PDFkit featuring in-code document creation and pages operations.

First article is about PDFKit basics & Ink annotations
Second is about PencilKit, Text annotations & auto-saving

Create PDF Document using Swift

In case you need to create a new PDF file on iOS device you won’t actually need to use PDFKit at all. There are few simple UIKit methods for that.

First, you need to create UIGraphicsPDFRendererFormat object to provide PDF document metadata such as author, etc.

let format = UIGraphicsPDFRendererFormat()
let metaData = [
    kCGPDFContextTitle: "Hello, World!",
    kCGPDFContextAuthor: "John Doe"
  ]
format.documentInfo = metaData as [String: Any]

You’ll find a full list of available metadata parameters in CoreGraphics framework reference documentation, just start typing kCGPDF in your code in Xcode.

Second, we need to calculate PDF page dimensions. PDF documents use a default resolution of 72 DPI. Page dimensions would be:

// US Letter
Width: 8.5 inches * 72 DPI = 612 points
Height: 11 inches * 72 DPI = 792 points
// A4 would be [W x H] 595 x 842 points

After doing this math, we need to instantiate UIGraphicsPDFRenderer object, which is responsible of document rendering.

let pageRect = CGRect(x: 0, y: 0, width: 595, height: 842)
let renderer = UIGraphicsPDFRenderer(bounds: pageRect,
                                     format: format)

Third, to start drawing just call .pdfData method of your renderer:

let data = renderer.pdfData { (context) in
// Perform your drawing here
}

You could call every drawing method of CoreGraphics framework here. But, first you need to create new PDF page by calling context.beginPage(). Call this code every time you need to start new page.
To draw a simple “Hello, world!” text use this code example:

let data = renderer.pdfData { (context) in
  context.beginPage()

  let paragraphStyle = NSMutableParagraphStyle()
  paragraphStyle.alignment = .center
  let attributes = [
    NSAttributedString.Key.font: UIFont.boldSystemFont(ofSize: 14),
    NSAttributedString.Key.paragraphStyle: paragraphStyle
  ]
  let text = "Hello, World!"
  let textRect = CGRect(x: 100, // left margin
                        y: 100, // top margin
                    width: 200,
                   height: 20)

  text.draw(in: textRect, withAttributes: attributes)
}

What’s just happened?

We started new PDF page.
Created new NSParagraphStyle object to add .center alignment to our text.
Created attributes dictionary containing font and paragraph style.
Created text String.
Created textRect struct describing specific rect where our text would be drawn.
Called .draw method of string object.

That’s it. Easy, right? Just provide your own attributes like color, font, etc.

Finally, we must save out PDF context to file on device. As rendered would return Data object, we have 2 ways of saving our document:

Initializing PDFKit's PDFDocument(data:) object and writing it to file

let pdfDocument = PDFDocument(data: data)
let path = PATH_TO_DESIRED_FILE
pdfDocument.write(to: path)

Using UIGraphicsPDFRendered's method writePDF instead of pdfData in third step. Let's replace

let data = renderer.pdfData { (context) in

with

let url = URL_TO_DESIRED_FILE
try? rendered.writePDF(to: url) { (context) in
  ...
}

You must add try? call because writing operation is throwable.

Insert page to PDF document

To add or remove pages to/from PDF document we need to use Apple’s PDFKit methods.
First, you need to initialize 2 PDF documents. One where the page would be inserted, and another from which we’ll take the page to insert.

let firstPDFDocument = PDFDocument(url: URL_TO_YOUR_FIRST_DOC)
let secondPDFDocument = PDFDocument(url: URL_TO_YOUR_SECOND_DOC)

Second, locate the page you want to insert and insert it at desired location:

// let's assume we want to insert 5th page of 2nd doc to 1st doc
let page = secondDocument.page(at: 5)
// And insert this page as first
firstDocument.insert(page, at: 0)

Don’t forget to save your document after insertion:

firstDocument.write(to: URL_TO_YOUR_FIRST_DOC)

Remove page from PDF Document

Removing pages is easy as well:

let pdfDocument = PDFDocument(url: URL_TO_YOUR_DOC)
pdfDocument.removePage(at: 0) // removing the first page
firstDocument.write(to: URL_TO_YOUR_DOC)

That’s it.

iOS PDFKit tutorial: Text Annotations & more

Artem Poluektov — Sun, 19 Mar 2023 13:35:59 +0000

This is the second article about Apple’s PDFkit featuring working with Text Annotations, document auto-saving and PencilKit.

First article is about PDFKit basics & Ink annotations
Third article is about creating PDF document on device and inserting/removing pages

PencilKit

We tried to implement PencilKit support in our app right after iOS 13 release. We even created a ticket to Apple Technical Support asking is there any easy way to do so. Short answer is NO.
You just can't use PencilKit together with PDFKit like how it works in native iOS markup screens.

Apple Technical Support answer:

The PencilKit team recommends developers put a PKCanvasView over each PDFPage. Signatures are a little different - you'd probably need to grab the PKDrawing from the PKCanvasView and then render the PKDrawing as an image inside of a PDFPage as you would a watermark.

Proposed solution seems to be impossible to implement (adding PKCanvasView to PDFPage). Second part (about grabbing PKDrawing) seems to be not the right way for our task too because of requirement to zoom page and erase previously added annotations. So, I feel that our solution from the first part of this tutorial is still the right one.

PKToolPicker seems not to be the right fit as well. It looks much better than out instruments view, but is completely not customizable. For example, in iOS 13 it features ruler, and if we don't need it in our app, we're still unable to remove it from ToolPicker. Hope, Apple would add some ways for customization in future releases.

Text annotations

Text annotations seems to be easier than drawing (Ink). However due to lack of documentation and sample code (again!) it wasn't an easy task.

So, let's assume we need to add some "Hello, world!" text to some place on a document's last page. To do so, write the code below (in your Drawing View Controller, for this example):

func addDateAnnotation() {
  guard let document = pdfView.document else { return }
  let lastPage = document.page(at: document.pageCount - 1)
  let annotation = PDFAnnotation(bounds: CGRect(x: 100, y: 100, width: 100, height: 20), forType: .freeText, withProperties: nil)
  annotation.contents = "Hello, world!"
  annotation.font = UIFont.systemFont(ofSize: 15.0)
  annotation.fontColor = .blue
  annotation.color = .clear
  lastPage?.addAnnotation(annotation)
}

First, you need a page where you want to add annotation. Then you need to set following properties:

contents: text to display,
font: font,
fontColor: foreground color,
color: background color.

That's it. Just don't forget to save your document.

Annotation types

In one of our tasks we needed to iterate through all annotations array to remove annotation of the specific type. We found that calling PDFAnnotationSubtype.freeText and annotation.type would actually return different results!

PDFAnnotationSubtype.freeText // "/freeText"
annotation.type // "FreeText"

So, to filter annotations of the specific type we had to call:

allPageAnnotations.filter { $0.type == "FreeText" }

instead of

allPageAnnotations.filter { $0.type == PDFAnnotationSubtype.freeText }

Next & Previous buttons

Implementing next & previous buttons [which are very useful for your users] is very easy. Just add those buttons in your Storyboard and call one of those methods:

pdfView.goToPreviousPage(nil)
// or
pdfView.goToNextPage(nil)

Auto-saving the document

Due to our long history with crashes we decided to implement auto-saving feature. We wanted to save PDFDocument after each successfully drawn annotation and used this code:

pdfDocument.write(to: url)

However, with larger documents this code caused UI freezes, so we tried to do it in background:

DispatchQueue.global(qos: .background).async {
  pdfDocument.write(to: url)
}

Which caused crashes when document's content changed during saving.
Our final solution was to use PDFDocument method dataRepresentation combined with simple Timer:

if let data = pdfDocument.dataRepresentation() {
  try? data.write(to: url)
}

This solution didn't cause crashes, but made PDFView blink on this call. The only working solution we found was:

create a copy of PDFDocument ,
apply all changes (adding/removing annotations) to visible document in PDFView and to copy, only add completed annotations due to performance,
save copy each 30 seconds (for example),
track all changes during saving: you cannot apply changes during save, so need to store changes history in memory during saving, which may take some time with a bigger files.

Useful links
You would find some initial information about PDFKit in this WWDC video:

https://developer.apple.com/videos/play/wwdc2017/241/

Here you'll find Apple's sample code of advanced drawing with Apple Pencil. Not sure it would work really great with PDFs due to performance issues.

https://developer.apple.com/documentation/uikit/touches_presses_and_gestures/leveraging_touch_input_for_drawing_apps

If you're looking for any alternative solution, check one of these frameworks. I haven't found any free or open-source solutions, and licenses for those in the list are pretty expensive ($500-$1K+).
PSPDFKit. Features drop-in replacement APIs for Apple's

PDFKit,
Foxit,
PDFTron.

iOS PDFKit Ink Annotations Tutorial

Artem Poluektov — Sun, 19 Mar 2023 13:32:49 +0000

This is my first article about Apple’s PDFKit. We’ll start with PDFKit basics and will create first Ink annotations in the end of this tutorial.

The second is about PencilKit, Text annotations and auto-saving.
The third article is about creating PDF document on devices, and inserting and removing pages.

My team recently started a new project: to develop a new iOS app with a built-in PDF Viewer.

The key feature of this viewer was the ability to add annotations to a PDF file with a finger or Apple Pencil. Of course, we understood it wouldn’t be an easy task, but we never imagined quite how challenging it would be.

At first sight, PDFKit looks like any other Apple’s framework included in iOS SDK. It includes views for PDF documents and thumbnails with built-in gestures support and lot of animations. It actually seems to be "magical" framework to solve our task in just a few lines of code.

However, I’d spent a lot of time making drawings, touches, and annotations work as expected. We also found a few bugs, which lead to crashes (inside the Framework), and lack of documentation and tutorials or examples.
That’s why I made this tutorial for you!

Updated for iOS 15

This tutorial was updated to iOS 15, you’ll also find some useful information about PencilKit, PKCanvasView and PKToolPicker introduced with iOS 13 in the second part, as well as how to add text annotations.
However, there were no major changes in PDFKit framework since iOS 13.

The task

The task was pretty simple:

Download a PDF file to the device.
View a PDF document and allow the user to navigate between pages.
Add ink annotations to a PDF with the user’s finger or an Apple pencil
Save a PDF document and upload it to the server.

Looks easy, doesn’t it? We don’t need to teach you how to use Alamofire for downloading and uploading files — we’ll go straight to PDFKit.

Note: In this tutorial, I’m going to build an iPad app, but PDFKit also works for iPhone.

PDFView

PDFView is the key object in PDFKit. It’s a subclass of UIView, and its main purpose is to display a PDF Document. To add one to your ViewController’s view, you could use either Storyboard or in-code initialization. Personally, I prefer Storyboard to quickly build an example project.

To add a PDFView to your ViewController’s view

Simply add new UIView
Setup constraints (I’m going to leave some space on the left for thumbnails view)
Go to the Inspector panel (on the right side), select Identity tab and enter the class name PDFView.

Now we can set up PDFView:
Create @IBOutlet to your ViewController’s class using Interface Builder
Don’t forget to import PDFKit
Here’s my PDFView setup code:



pdfView.displayDirection = .vertical
pdfView.usePageViewController(true)
pdfView.pageBreakMargins = UIEdgeInsets(top: 0, left: 0, bottom: 0, right: 0)
pdfView.autoScales = true
pdfView.backgroundColor = UIColor(white: 0.95, alpha: 1.0)

The first line is pretty simple — your PDFView can have either a vertical or horizontal scrolling direction.

The second line is very useful. By default, PDFView uses the built-in UIScrollView to enable a continuous scroll across the whole document. However, you may activate PageViewController mode, so that the PDFView shows only one page at the screen. Of course, zooming is supported and enabled by default.

I found that the .autoScales setting contains a bug. It doesn’t work on iPad when the screen rotates. To solve this issue, you have to add this call:



override func viewWillTransition(to size: CGSize, with coordinator: UIViewControllerTransitionCoordinator) {
  pdfView.autoScales = true
}

Another method with unexpected behavior is .backgroundColor. It works in code only and doesn’t work when you’re trying to set it in Interface Builder. I spent a long time trying to understand what I had done wrong!

Finally, I was able to find the reason: Calling pdfView.document = ... resets PDFView’s background color to default. So, call pdfView.backgroundColor = ... after pdfView.document = ....
After completing PDFView setup, let’s add an example PDF document to your project (drag and drop it to the left panel):

Create PDFDocument and add it to your PDFView:



guard let path = Bundle.main.url(forResource: "YOUR_FILE_NAME", withExtension: "pdf") else { return }
pdfView.document = PDFDocument(url: path)

That’s easy!

Now we have our app up and running with these out-of-the-box features:

Zooming with the two-finger gesture.
Scrolling.
Long-pressure gesture to call the copy menu.
ThumbnailView support.

This is what my viewDidLoad method looks like after this step:



override func viewDidLoad() {
super.viewDidLoad()
// Setup PDF View
pdfView.displayDirection = .vertical
pdfView.usePageViewController(true)
pdfView.pageBreakMargins = UIEdgeInsets(top: 0, left: 0, bottom: 0, right: 0)
pdfView.autoScales = true
// Load PDF File
guard let path = Bundle.main.url(forResource: "241_introducing_pdfkit_on_ios", withExtension: "pdf") else {
print("file not found")
return
}
pdfView.document = PDFDocument(url: path)
// Set background color after setting new document
pdfView.backgroundColor = .systemBackground
}

Note: It’s not the best idea to put so many lines of code in your viewDidLoad, but it’s a tutorial, so let’s just leave it!

PDFThumbnailView

Creating a thumbnail view is easy. Like we just did in the previous step:

Add new UIView to your ViewController’s view (not PDFView’s subview).
Setup constraints.
Set PDFThumbnailView as a class name in the Identity Inspector tab in the right panel.
Create @IBOutlet to your ViewController’s code.

Use this code in your viewDidLoad method to set up your new Thumbnail View:



thumbnailView.pdfView = pdfView
thumbnailView.thumbnailSize = CGSize(width: 100, height: 100)
thumbnailView.layoutMode = .vertical
thumbnailView.backgroundColor = UIColor(white: 0.9, alpha: 1.0)

This code is clear. I have to mention that PDFThumbnailView, like PDFView, doesn’t respect the .backgroundColor Interface Building setting. However, it stores color you set, so you don’t have to reset it every time when calling pdfView.document = ....

Unfortunately, we had crashes with PDFThumbnailView on iOS 12 when the user tried to add annotations. In one case user was able to draw for an hour with no crashes but in other cases, the app crashed after the first annotation. It seems to have been fixed in iOS 13.

Receiving Touch Events

Initially, to implement user input, I tried to add transparent UIView as pdfView's subview. I found that transparent views do not receive touch events.

Then I set alpha to 0.01, the minimal alpha for view to receive touches. However, I still had an issue with zooming and scrolling gestures. I wanted my transparent view to receive one-finger gestures and forward other (two-finger) gestures to its parent view ( pdfView ). I finally found that this approach just wouldn’t work.

So, finally, I implemented my own custom gesture recognizer. It only works with one-finger gestures and fails if the gesture has multiple fingers. Here is the code:



class DrawingGestureRecognizer: UIGestureRecognizer {
  weak var drawingDelegate: DrawingGestureRecognizerDelegate?
  override func touchesBegan(_ touches: Set<UITouch>, with event: UIEvent?) {
    if let touch = touches.first,
    touch.type == .pencil,
    let numberOfTouches = event?.allTouches?.count,
    numberOfTouches == 1 {
      state = .began
      let location = touch.location(in: self.view)
      drawingDelegate?.gestureRecognizerBegan(location)
    } else {
      state = .failed
    }
  }
  override func touchesMoved(_ touches: Set<UITouch>, with event: UIEvent?) {
    state = .changed
    guard let location = touches.first?.location(in: self.view) else { return }
    drawingDelegate?.gestureRecognizerMoved(location)
  }
  override func touchesEnded(_ touches: Set<UITouch>, with event: UIEvent?) {
    guard let location = touches.first?.location(in: self.view) else  {
      state = .ended
      return
    }
    drawingDelegate?.gestureRecognizerEnded(location)
    state = .ended
  }
  override func touchesCancelled(_ touches: Set<UITouch>, with event: UIEvent) {
    state = .failed
  }
}

First, I implemented the touchesBegan method, where it analyzes the touch it received.

If it’s Apple Pencil and a one-finger gesture, I set the gesture recognizer state to .began and continue receiving touch events. You could comment the Pencil line to make this code work on iOS Simulator. You cannot simulate Pencil on your Mac, unfortunately. If it’s multi-touch gesture, I set gesture recognizer state to .failed, so that other pdfView's gesture recognizers work.

In touchesBegan I’m also notifying my delegate that we received a new touch event so it could create the new PDFAnnotation. In the touchesMoved method I’m only notifying the delegate about new touches locations.

Finally, in the touchesEnded method, I’m sending the final touch location and notifying my delegate that touch has ended.
Here’s the protocol reference — it’s quite simple:



protocol DrawingGestureRecognizerDelegate: class {
func gestureRecognizerBegan(_ location: CGPoint)
func gestureRecognizerMoved(_ location: CGPoint)
func gestureRecognizerEnded(_ location: CGPoint)
}

Add this gesture recognizer to your PDFView by adding this code to your ViewController’s viewDidLoad method:



let pdfDrawingGestureRecognizer = DrawingGestureRecognizer()
pdfView.addGestureRecognizer(pdfDrawingGestureRecognizer)

Coalesced and Predicted Touches

Each touch event (UIEvent) from our gesture recognizer also has coalesced and predicted touch arrays. Due to different device hardware and to improve performance, only some touch events are being received by the gesture recognizer in real-time.

If your app needs better precision, you could access all touches by checking UIEvent's coalescedTouches property. iOS would also try to predict the user’s finger or pencil movement and create a predictedTouches array for each UIEvent.

According to Apple’s documentation, you could store coalescedTouches and use them for drawing. However, you must remove any drawing used data from predictedTouches when you receive the next touch event.

We tried to forward the gesture recognizer’s delegate not only the location of current touch, but also the arrays of coalesced and predicted touches. However, it caused performance issues, so in the final implementation we decided to stuck with just regular touch events and skipped coalesced and predicted touches. In our case, it didn’t affect user experience in the end.

Drawing Implementation

After we created the gesture recognizer, we need to implement drawing. I’ll try to follow the single-responsibility principle and create another class to handle drawing. Let’s call it PDFDrawer:



class PDFDrawer {
  weak var pdfView: PDFView!
  private var path: UIBezierPath?
  private var currentAnnotation : PDFAnnotation?
  private var currentPage: PDFPage?
}

Our PDFDrawer should hold a reference to PDFView, to which we add our annotations. Path is used to store all touch events in a single gesture. CurrentAnnotation reference is also required because we add new points to our path whenever the user moves their Apple Pencil, so we need to update it. CurrentPage is also required for cases where a user starts a gesture on one page and then accidentally moves to the next page.

Here I should explain how PDFDocument works. The document contains pages which are represented by the PDFPage class. Each page contains its own annotations of class PDFAnnotation. So, in the case where a user starts a gesture on one page and moves touches to another page, we have to keep drawing on the initial page.

PDFDrawer is gesture recogniser’s delegate, so we need to implement three methods of DrawingGestureRecognizerDelegate protocol. First, one is called on the user’s first touch:



func gestureRecognizerBegan(_ location: CGPoint) {
  guard let page = pdfView.page(for: location, nearest: true) else { return }
  currentPage = page
  let convertedPoint = pdfView.convert(location, to: currentPage!)
  path = UIBezierPath()
  path?.move(to: convertedPoint)
}

Here we storing current page reference and creating new UIBezierPath for the new drawing.

When the user moves their finger or Pencil the following method is called:



func gestureRecognizerMoved(_ location: CGPoint) {
  guard let page = currentPage else { return }
  let convertedPoint = pdfView.convert(location, to: page)
  path?.addLine(to: convertedPoint)
  path?.move(to: convertedPoint)
  drawAnnotation(onPage: page)
}

This checks if the current page reference exists, adds a new point to our path, and adds drawing annotation. I will provide the drawAnnotation method implementation later.

When the user finishes their touch, exactly the same code is called. Or at least, it’s the same at this stage of the tutorial, but we will add some specific code later to implement an eraser.



func gestureRecognizerEnded(_ location: CGPoint) {
  guard let page = currentPage else { return }
  let convertedPoint = pdfView.convert(location, to: page)
  path?.addLine(to: convertedPoint)
  path?.move(to: convertedPoint)
  drawAnnotation(onPage: page)
  currentAnnotation = nil
}

Easy, right? Initially, I tried to reuse one annotation across began, moved, and ended events. I added a new UIBezierPath to the current annotation every time by calling .add(UIBezierPath) method of PDFAnnotation. However, we found that the app crashes somewhere inside the PDFKit framework.

So instead of calling .add on one annotation, I create a new annotation every time touch moves and remove the old one. This (adding and removing) is visible on iOS Simulator but works smoothly on a real iPad. This is the only solution I’ve found that does not causes crashes inside the PDFKit Framework.

Here’s my code to create the annotation:



private func createAnnotation(path: UIBezierPath, page: PDFPage) -> PDFAnnotation {
  let border = PDFBorder()
  border.lineWidth = 5.0 // Set your line width here
  let annotation = PDFAnnotation(bounds: page.bounds(for: pdfView.displayBox), forType: .ink, withProperties: nil)
  annotation.color = .red
  annotation.border = border
  annotation.add(path)
  return annotation
}
private func drawAnnotation(onPage: PDFPage) {
  guard let path = path else { return }
  let annotation = createAnnotation(path: path, page: onPage)
  if let _ = currentAnnotation {
    currentAnnotation!.page?.removeAnnotation(currentAnnotation!)
  }
  onPage.addAnnotation(annotation)
  currentAnnotation = annotation
}

Another issue that forced us to use this solution is the feature request from our client. They wanted not only drawing with full color but also to be able to draw with transparent color (with alpha component).

The default PDFAnnotation with few paths looked really bad. Because it consisted of few transparent paths, the points where one path ends and the other begins were brighter than lines because of intersections. Because all the drawing is performed inside PDFKit, we’re unable to change that. That’s why we used our solution instead.

Finally, to make things work, we need to create a PDFDrawer property in our ViewController:



private let pdfDrawer = PDFDrawer()

And add this setup calls, for example, in viewDidLoad method:



pdfDrawingGestureRecognizer.drawingDelegate = pdfDrawer
pdfDrawer.pdfView = pdfView

Long Pressure Gesture Recognizer

As I mentioned above, PDFView contains a lot of built-in gesture recognizers. In some rare cases, our custom gesture recognizer conflicted with built-in long-pressure gesture recognizer used to copy action. We haven’t found any setting of PDFView to disable it, so we had to implement this subclass of PDFView:



import UIKit
import PDFKit
class NonSelectablePDFView: PDFView {
// Disable selection
  override func canPerformAction(_ action: Selector, withSender sender: Any?) -> Bool {
    return false
  }
  override func addGestureRecognizer(_ gestureRecognizer: UIGestureRecognizer) {
    if gestureRecognizer is UILongPressGestureRecognizer {
      gestureRecognizer.isEnabled = false
    }
    super.addGestureRecognizer(gestureRecognizer)
  }
}

Custom PDFAnnotations

We also experimented with custom PDFAnnotations. As I mentioned above, we needed to remove and add new PDFAnnotation after receiving new touch events.

We tried to use a single annotation from the beginning of the gesture to its end, to improve drawing performance. So, we created a custom annotation class with path property and overridden draw() method.

However, we were unable to force PDFKit to redraw the annotation every time we modified the path because PDFAnnotation is not UIView and does not have any methods for that.

Finally, we decided to add and remove the same annotation from the page every time we received a new touch event (without creating a new one). With custom draw method we achieved visual drawing performance increase noticeably improving user experience. Here’s the draw() method:



class DrawingAnnotation: PDFAnnotation {
  public var path = UIBezierPath()
  override func draw(with box: PDFDisplayBox, in context: CGContext) {
    UIGraphicsPushContext(context)
    context.saveGState()
    color.set()
    path.lineWidth = border?.lineWidth
    path.stroke() // this is actual drawing call
    context.restoreGState()
    UIGraphicsPopContext()
  }
}

To eliminate drawing artefacts we add some extra settings to the draw() method:



path.lineJoinStyle = .round
path.lineCapStyle = .round

To make this method thread-safe we replaced path the copy inside the draw() method:



override func draw(with box: PDFDisplayBox, in context: CGContext) {
  let pathCopy = path.copy() as! UIBezierPath
  UIGraphicsPushContext(context)
  context.saveGState()
  context.setShouldAntialias(true)
  color.set()
  pathCopy.lineJoinStyle = .round
  pathCopy.lineCapStyle = .round
  pathCopy.lineWidth = border?.lineWidth ?? 1.0
  pathCopy.stroke()
  context.restoreGState()
  UIGraphicsPopContext()
}

Custom Annotations and Performance

After the first release, we found another performance issue. Users experienced freezes on scrolling and zooming PDF documents with our custom annotations. Some even crashed due to memory warnings — even in-system and third-party apps.

To fix this issue and maintain a great drawing experience we decided to use custom annotation while the user is drawing and replace it with the system PDFAnnotation right after the user finishes touch. We also added new bounds calculation mechanics to minimize final annotation’s bounds size, reducing memory usage and improving drawing performance. I’ll remind you that we used whole page size as the bounds for our custom annotation during the drawing process — the user can draw over the whole page, quickly and smoothly.

Updated PDFDrawer gestureRecognizerEnded method:



func gestureRecognizerEnded(_ location: CGPoint) {
  guard let page = currentPage else { return }
  let convertedPoint = pdfView.convert(location, to: page)
  // Erasing
  if drawingTool == .eraser {
    removeAnnotationAtPoint(point: convertedPoint, page: page)
    return
  }
  guard let _ = currentAnnotation else { return }
  path?.addLine(to: convertedPoint)
  path?.move(to: convertedPoint)
  // Final annotation
  page.removeAnnotation(currentAnnotation!)
  currentAnnotation = nil
  createFinalAnnotation(path: path!, page: page)
}

In this method we’re still updating path, then removing the old (custom) annotation and creating final (system) annotation:



private func createFinalAnnotation(path: UIBezierPath, page: PDFPage) -> PDFAnnotation {
  let border = PDFBorder()
  border.lineWidth = drawingTool.width
  let bounds = CGRect(x: path.bounds.origin.x - 5,
                      y: path.bounds.origin.y - 5,
                  width: path.bounds.size.width + 10,
                 height: path.bounds.size.height + 10)
  var signingPathCentered = UIBezierPath()
  signingPathCentered.cgPath = path.cgPath
  signingPathCentered.moveCenter(to: bounds.center)
  let annotation = PDFAnnotation(bounds: bounds, forType: .ink, withProperties: nil)
  annotation.color = color.withAlphaComponent(drawingTool.alpha)
  annotation.border = border
  annotation.add(signingPathCentered)
  page.addAnnotation(annotation)
  return annotation
}

That’s it. Great performance during drawing and previewing. Just don’t forget to add the UIBezierPath+.swift file to your project if you’re going to use my code. You may find it in the sample code at the bottom of this tutorial.

Eraser

We also needed to implement an eraser tool. However, we were unable to use the annotation(at:CGPoint) method provided by PDFPage because it’s based on annotation’s bounds and returned annotation even when the user tapped on white space inside bounds rect.

In our case (where the user may write text with an Apple Pencil) it didn’t work as the user would expect. We needed to find out whether the path was tapped, not the path’s bounds. First, we implemented PDFAnnotation subclass with computable hitPath property (more details on that later) which is the final path of annotation. For performance reasons, it’s only calculated when the path is completed.

We found that this approach doesn’t work after closing the PDFDocument and opening it again, because all the previously created annotations of class PDFAnnotationWithPath became regular PDFAnnotation. So, we had to sacrifice a bit of performance and create an extension instead of subclass:



extension PDFAnnotation {
  func contains(point: CGPoint) -> Bool {
    var hitPath: CGPath?
    if let path = paths?.first {
    hitPath = path.cgPath.copy(strokingWithWidth: 10.0, lineCap: .round, lineJoin: .round, miterLimit: 0)
    }
    return hitPath?.contains(point) ?? false
  }
}

It’s important to note that we’re using paths property of PDFAnnotation here — make sure to put your final path there. We’re also using ten points as the default stroking width for all lines to make it easier for the user to hit the path with the eraser.
We also implemented PDFPage extension to call the contains method:




extension PDFPage {
  func annotationWithHitTest(at: CGPoint) -> PDFAnnotation? {
    for annotation in annotations {
      if annotation.contains(point: at) {
        return annotation
      }
    }
    return nil
  }
}

Finally, we need to update PDFDrawer methods to support the eraser tool:



func gestureRecognizerMoved(_ location: CGPoint) {
  guard let page = currentPage else { return }
  let convertedPoint = pdfView.convert(location, to: page)

  // Erasing
  if drawingTool == .eraser {
    removeAnnotationAtPoint(point: convertedPoint, page: page)
    return
  }


  // Drawing
  ...
}

DrawingTool is an enum, containing all the drawing tools we have. Users may select different tools with different line width and color in the UI. We’re storing it as a property of PDFDrawer.
Apply the same changes to gestureRecognizerEnded method:



func gestureRecognizerEnded(_ location: CGPoint) {
  guard let page = currentPage else { return }
  let convertedPoint = pdfView.convert(location, to: page)
  // Erasing
  if drawingTool == .eraser {
    removeAnnotationAtPoint(point: convertedPoint, page: page)
    return
  }
  // Drawing
  ...
}

Here’s removeAnnotationAtPoint implementation:



 private func removeAnnotationAtPoint(point: CGPoint, page: PDFPage) {
  if let selectedAnnotation = page.annotationWithHitTest(at: point) {
    selectedAnnotation.page?.removeAnnotation(selectedAnnotation)
  }
}

Saving the Document

Saving your PDFDocument after adding all the annotations you need is also very easy:



let path = Bundle.main.url(forResource: "YOUR_DOCUMENT_NAME", withExtension: "pdf")
pdfView.document?.write(to: path!)

Here’s the final view of our app:

Sample Code

For a demo project, please check the repository.

I didn’t create a library or framework intentionally. Mostly because all the apps/projects to work with PDF are so different and require a lot of customizations. So, guys, feel free to use my sample code as a base for your own project.

Continue Reading

To learn more about PDFKit, including working with PencilKit, adding text annotations, and alternative solutions, continue to the second part.