Now that we launched our client app for the official Zeplin API on iPhone we brought our attention on making the app a good fit for the iPadOS. Being a project we usually work on in our Fridays, some corner-cutting had to be done to hit the market faster. The first version of the app was aimed towards providing the ability to discuss designs on smaller screens.

The iPad was always on our radar but with the initial launch the tablet app was just a letterboxed version of the phone app. That was just unacceptable.

We do feel that iPad has an enormous potential of being a great productivity device and we wanted to experiment a bit with where can we go with that in mind.

It wasn’t as easy as ticking a checkbox, though. There is a fair bit of customization going on in the iPhone version of the app that had to be dealt with to fit iPadOS better.

We can’t stress enough how much of a difference using split views brings to the app interaction on the tablets. The bigger space gives you the opportunity to accommodate more information in a very useful way. We wanted to have a sidebar with the projects list that is always visible. In a very short amount of time, we had a proof of concept that allowed us to switch projects from entry points that were not possible before.

On the phone, you can tap twice on the image in the screen details view to trigger what we call ‘the full screen mode”. That mode allows you to preview designs on the device without any app chrome and we wanted to keep the same interaction on the tablets as well.

You can hook a keyboard to an iPad and it made sense to us to provide a keyboard shortcut for the interaction. While we were at it we added some shortcuts for going to the previous/next screen in the details view as well. You can still do that by swiping but the shortcuts were another way to make our app “a good citizen” of the platform.

We use custom expandable bottom sheets to host some of the supplementary info (project members, screen versions) and we have an integration between the comments sheet and the screen previews. Although it works (and looks) great on the phone, it does not feel particularly good fit for the bigger screens.

There’s a modal presentation style that adapts its layout and behaviour depending on the screen size that Apple is using throughout the iPadOS. We like the approach a lot and we put in some work in making our custom presentations to behave in the same fashion. Again, it did not took us long before we started to see our custom presenters acting as expected.

We looked at our habits of using iPhoneOS. Using the system’s split view to display two apps side by side is a thing we do a lot and we wanted our app to be part of it. We decided to stay off allowing multiple windows for now, but the app can be displayed next to any other app in the split view mode. We also recognised that you may want to be able to export the screen thumbnails on the tablet for further use and we added support for that.

The variety of the screen sizes was another thing we did some explorations around. We tweaked our project and screen lists to show more info on the larger screens. As a result we now show from 3 to 5 thumbnails in a row, depending on the size of the iPad. We keep the size of the UI elements roughly the same, but the bigger screens look less empty now.

This is just our first delivery of the app on the tablets. We often say that software is never done and there are plenty of things we want to do with the next updates. One thing is sure, though — we are going to have fun doing it.

‎Zeplin Mobile by Snapp Mobile

Bringing Zeplin Mobile to iPadOS was originally published in Snapp Mobile on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduced at the 2019 WWDC, SwiftUI caught a lot of developers’ attention. People started to share bits and pieces on their personal experience with it mostly because besides the great set of introductory lessons, Apple didn’t share any documentation. The shift from what building apps using UIKit is to what SwiftUI promises to be is so dramatic that we naturally decided to give it a go.

One of the things we truly believe in at Snapp Mobile is the power of prototyping as a learning tool. As soon as we started toying around SwiftUI though, we realized that a prototype simply won’t be enough to gain the depth of knowledge we were interested in.

So, we decided to learn SwiftUI by writing an app. Actually, by porting an Android one to iOS. There’s a quite cool Android app to learn the Cyrillic alphabet made by our colleague Juhani Lehtimäki that we wanted to port on iOS for a few reasons. First, it’s small enough not to cloud our availability. Second it’s complex enough UI and UX-wise to go beyond being a traditional SwiftUI exercise, and third… we had no iOS version of it :)

There were a few targets that we wanted to hit: we wanted it to look and feel as a brother of the Android app but to embrace the iOS design language and behavior.

We wanted the app on iPadOS. And on watchOS.

True to what Apple promised, it turned easy to reuse most of the UI components between iOS, iPadOS and watchOS, we only had to handle the minor details to get our components fit the platform language. We learned very quickly to avoid large view components. We broke our UI into small, reusable views which was beneficial when we reused them on watchOS later.

Another thing that made sense to us during the discovery process was to decouple the app logic and the data flow out of our UI code. There’s another great framework that was introduced at the very same WWDC that is kinda tied to SwiftUI, named Combine. We used Combine on some of the internals like loading and storing the alphabets and for generating and tracking the quizz progress.

There was a set of explorations around how we would like to structure our SwiftUI apps. Since reusability was a factor we built a shared framework that contains our app logic and our data models which gets used between all of the platforms. As SwiftUI is a declarative UI framework by nature we went with using a lightweight, in-house baked implementation of the Flux architecture to carry the data flow. This means that our state, actions and reducers live in the said shared library along with the data models. The result is a framework that we can use outside of the SwiftUI context, if needed.

Lastly, there was a fair amount of exploration around some of the advanced SwiftUI topics, including PreferenceKeys and AnimatableModifiers. To strengthen the platform integration we threw in some haptic feedback where we felt we need it. The end result is an app that feels snappy, responsive and pleasing. We do hope you like it.

TL;DR: LearnCyrillic is now live on AppStore.

‎Learn Cyrillic

Building our first SwiftUI-only app — LearnCyrillic was originally published in Snapp Mobile on Medium, where people are continuing the conversation by highlighting and responding to this story.

No matter what we do at some point in our careers as developers we all face the dilemma of introducing external dependencies to our projects. We are pretty sure that you, dear reader, have faced it too. If you did not, you will, we promise you, it’s as inevitable as the chickenpox.

There are various reasons to rely on third-party code. It could be because you want to measure your app adoption and you don’t want to waste time writing the measurement layer. Or because you have to introduce a functionality that deals with a matter that you don’t quite have the experience with. Or because your dev buddies told you about that library that is going to sort out most of the existing issues that your app has. Or because that library had been there since the day you started working on the project in the first place. Or simply because you don’t want to deal with some of the basics every time you start a new app. Everybody hates boilerplate, right?

All of the above are valid reasons, but…

Picking a dependency can be a tricky process

There are few things that you should take into consideration:

• Acknowledge the fact that adding a dependency makes it your code. Even if you have not authored it, it ships with your app, it’s part of your app’s workflows, some logic relies on it, so it’s your code too. You are responsible to maintain it (even if that maintenance goes as much as keeping the dependency updated).
• Make an informed decision. A google search might yield you a handful of options. How would you choose which one to pick? We would check the history of the dependency. It’s easy for most of the public libraries — just check the project on github. Look for things like how frequently the project gets updated. It might not seem important at first sight, since it does the job, right? But imagine it being a UI library that has no support for the next iPhone which is going to have two notches (figuratively speaking, you’ll see lots of that). Can you afford losing clients by waiting for the authors to update their libs 2–3 weeks (or more) after the device is on the market? It happens to the best apps on the AppStore, for real, it may happen to you too. We’d render suspicious a project that has no release in the last 3 to 6 months.
• Take a look at the list of the known issues of that dependency, the less they are, the better. Check the tone of the discussions, the age of the topics. Try to get a sense of how fast the bugs are getting resolved. You don’t want your app to host a bug that hasn’t been fixed in the past 2 years. You also don’t want to deal with people who are rude towards the bug reporters.
• Check the quality of the code. Some libraries start as side projects or are being used to demo the skills of their developers. Once in awhile a library becomes unmaintained because of various reasons — the author might get engaged into something else, or could simply lose his will to maintain the library. Depending on how deep the integration with your project is, dealing with such problems could be unpleasant. This can put you to a position to fork the project and to continue maintaining it yourself. It’s always better to know that you will enjoy doing so (and that you understand what’s going on to a degree that you can maintain it, of course). Or it may shift your attention from introducing new functionality to your apps to figuring out a suitable replacement.
• Consider treating the company-backed libraries equally to the single developer-driven ones. Most of the times, companies are looking at the libraries from the same perspective as the single developers — as a tool to promote themselves. Some companies make money out of their libraries. Every now and then a company gets acquired and changes its vision in consequence. This can also put you in a position to figure out a replacement. And if such a thing is at the foundation of your data stack, it could be a pain.
• Checking the capabilities of the library and figure out how would you utilise them. Would you use 1/10th of it’s capabilities? Do you really, really, really need to take the next 90% with your app for the price of these 10%. You may end up getting inspired to code these 10% of functionality alone.
• Make sure that you are aware of the fact that third-party code also has bugs that can be critical sometimes. This means that you have to be prepared for a situation where you have to deal with a third-party bugfix in the middle of your new feature development process. This could affect how you manage the code of your app, it may also have an impact on the testing workflows and so on.

So what, avoid dependencies?

No, not really. There’s a lot of great stuff out there that you can’t simply ignore. In fact it’ll be expected from you to know how to deal with some of the most popular libraries.

A library with some community around it (that also passes the checklist above) is what we usually consider a good candidate to get added to our projects.

A library that is well-maintained by a single dev can also be a good option. Find that guy on Twitter, drop him a line, tell him that you are interested in what he’s doing. Ask him about his plans for the project, and who knows, you may discover a new dev buddy.

Try to avoid leaning on third-party code for small, utility-like stuff. You know, things like the next fancy UICollectionView layout for example. Or that fancy String extension that’s wrapped in a pod. Also, do you really need all of the features of that third-party image loading library? Or that JSON-to-object library that’s been in your project for the past 3 years. You will learn so much if you code and manage these bits of your apps on your own, we promise you.

At the end of the day it’s you who’s in the driving seat of your app. It’s you who decides how much control over its features you want to have. It’s up to you to choose where to steer it at, and how to manage it. We just hope that the above may help you in the process of deciding on your dependencies next time.

On project dependencies was originally published in Snapp Mobile on Medium, where people are continuing the conversation by highlighting and responding to this story.