What are the main things you have to be cautious about when writing for mobile?
A mobile phone is more prone to network problems than a standalone computer. The user can move, going to some tunnel or area without WiFi or cellular network access. So the internet is not always available, or is not of the best quality. The phone may frequently switch between networks. Loading tons of heavy data when users use their cellular network will drain their data packets and expose them to additional costs. The developer might provide an offline mode and different data loading behavior when working on WiFi, LTE, 3G or H; e.g., do not download movies or request lower-quality images.
Developers must be aware that the device on which they are testing their app is just one of thousands of devices their users will use. They have to check how the app looks in smaller phones, bigger phones, tablets, etc., and adapt the layout to them.
Developers must also take into account the number of different system versions in use (mostly on Android phones), decide which are supported, and know the differences between them. Also, the app might have some bugs on devices from different manufacturers, so it is always good to have variety of physical devices for testing or use a test-device farm.
Although we have more and more memory in our phones, taking care of good memory management is still necessary. The OS will kill apps that use too much memory, so a developer must care about memory leaks and optimize long-running operations.
As with memory, manufacturers give us more and more disk space. For some devices, it’s also possible to extend this using SD cards.
Despite that, the developer should try to keep the app as small as possible. Having to download 500 MB to use a small app like a calculator will discourage users from trying the app in the first place.
But also once installed, keeping unnecessary files and otherwise taking up too much space may lead to users uninstalling the app and looking for a better alternative.
This is one of the weakest points of contemporary phones. Every action we take in an app affects the battery.
Users will certainly remove apps that use too much battery. The developer must take care when it comes to using different services like GPS. Developers should use such features only when necessary and use optimized OS solutions to update data in the background.
What is the best way for a server to notify an app that some new data is available?
To receive information from a server without polling via a series of requests, a mobile app might use push notifications. This is a better solution than constantly requesting new data, because it will not drain the battery and will use less network data.
Android and iOS each have their own solution for that:
- Apple Push Notifications sends push notifications to iOS devices only.
- Firebase Cloud Messaging is Google’s mechanism for sending push notifications to devices and has replaced Google Cloud Messaging (GCM). This is touted as “multi-platform,” meaning that it also supports iOS devices, relaying via the Apple Push Notification service (APNs) under the hood.
How can you debug your app when it’s already released?
There are lot of tools that provide crash and usage reports from mobile apps.
One of the most popular (and free) is Firebase Crashlytics, which supports both iOS and Android. It provides a lot of useful information about app crashes like the full-stack trace, operating system version, device manufacturer, and user language.
Describe the process of publishing apps on Google Play and in Apple’s App Store. What do you need to publish an app to each store?
Both Google Play and the App Store require images, an app description, and a unique identifier.
Google requires that you have a developer account to publish apps.
When an app is ready, it should be built into an APK file.
The APK must be signed to prove that it comes from your specific company. The signing is done using a keystore, which is a file containing one or more private keys belonging to the company/developer. (If this file is lost, no updates can be done for the app.)
Google has also introduced a new publishing system called Android App Bundles, which offers a smaller APK size and manages signing, but it’s not available for older Android versions.
After sending files, it may take a few hours until the app is available in the store.
The App Store
Apple requires a developer account connected with the Apple Developer Program to publish apps here.
First, the app must have a profile created for it in iTunes Connect.
The finished app is built into an IPA file, which has to be signed by some certificates. Xcode helps to do it all automatically using the Distribution Certificate (DC) and the Provisioning Profile, which connects the DC to the app ID.
Once sent, the app is checked by a team at Apple. It may take several days until the app is approved (or rejected) for publishing.
How can sensitive data like contacts or access to the camera (or other sensors) be secured in the world of mobile apps?
Access to a user’s data or sensors is restricted by a permissions system. That means that when the app wants to use a feature like GPS, it has to ask the user for permission and explain why this permission is necessary.
The user can agree, or reject the request. The developer must foresee rejecting and provide a way to still use some of the app’s features, which can work without the rejected sensor or data. Permissions can be granted or denied not only when the app is run but also from the user’s settings, so the app has to always check for it.
The permissions mechanism can change between OS versions, so the developer has to be aware of that. For example, on Android below version 6.0 (Marshmallow), permissions were declared in
AndroidManifest.xml, and users granted all of them during the app’s installation.
How can you store data in Android and iOS? Which databases and native solutions are available?
The native data storage solution for Android is
SharedPreferences. This is intended to store small amounts of data, like user preferences or settings. The data are stored in an XML file.
There is a similar solution for iOS called
NSUserDefaults). The data are stored in a
Both platforms have the possibility to use SQLite and provide frameworks and libraries to operate on the data (though it is possible to use the database manually):
- iOS has Core Data, a framework to manage object graphs. It can use SQLite, but might also save data in a binary store or just in memory.
- Android has the Room persistence library, which simplifies managing SQLite databases and reduces boilerplate around database usage.
The other possibility is Realm, a non-relational database system designed for mobile devices. It’s also available for hybrid solutions like Xamarin or React Native and is more efficient than SQLite.
What is the difference between native apps and hybrid apps? What are the advantages and disadvantages of hybrid apps?
Native apps are written specifically for one platform, in the language used on said platform, i.e. Objective-C or Swift for iOS, and Java or Kotlin for Android. These apps have the best performance and can be designed for the specific platform which users are used to, so iOS users will not be surprised by some Android behavior or layout and vice versa.
Hybrid apps have worse performance than native apps, though. Access to device hardware (like sensors) might be problematic sometimes, and very often has to be written separately for each platform, so the developer must get into native code and write platform-specific things anyway.
It is also very hard to design one app that looks nice and is user-friendly for both iOS and Android. On the other hand, the process of writing a hybrid app might be cheaper and faster than writing a native app for each platform. This technique is especially suitable for small and simple apps.
How can you deal with the plethora of different screen resolutions and screen sizes out there? What unit has been introduced to simplify positioning and sizing elements? How do you deal with images?
Both Apple and Google have introduced their own unit to help developers deal with different screen resolutions. For Apple, they repurposed (or perhaps modernized?) the term “point” (pt) to no longer be 1/72nd of an inch, but to be 2x that on retina displays, or 3x that on larger retina displays—but the exact scaling is not always an integer multiple like that.
Google, instead, uses a relatively new term, the “density-independent pixel” (DIP or “dp”). The idea behind both strategies is the same: to hide the real screen resolution and give programmers a unit independent of pixels.
Each device has a scale factor of how many pixels corresponds to one point (or density pixel). That means that when an iOS developer says that an image is 80 pt x 80 pt, the real size in pixels will be 80x80 on some very old devices (e.g., the iPhone 3G), 160x160 on the iPhone 6, and 240x240 on the iPhone X.
The same rule is true for Android phones; however, there are a greater number of possible scale factors on this platform.
Handling different screen sizes is very important also for designers, since they have to prepare graphics for each density group. Sometimes it is good to prepare different layouts for phones and tablets, or even portrait and landscape orientation.
When possible, images in SVG format should be used. They can be scaled without losing quality and they take less space than the same image in different sizes. Both Android and iOS support using SVG images.
Also, both platforms support layout constraints. Using this technique, elements can be placed in relation to other elements or screen edges. This gives a more responsive design on different screens and orientations.
What is app sandboxing and what is it for?
App sandboxing is a security mechanism that isolates apps at the kernel level. Each app is run in its own sandbox, which means that it has a very limited access to data: It can access only its own data and files, and no other app can read or write them.
This is to protect user data from malicious software which might be accidentally or intentionally installed on the device. Apps are still able share some data, but only the data they want to, using mechanisms provided by the system (e.g.,
ContentProvider on Android).
What are internationalization and localization? Do these terms mean the same thing?
No, these terms are not synonyms, but they are related. They’re both relevant to making the app available (and user-friendly) in languages other than the default language.
Internationalization (“i18n”) is the process of adapting app code to other languages. For example, an app might need to display data in a different format, prices, or numbers with the correct decimal or thousands separators, or even handling whether text is written right-to-left or left-to-right. It also requires taking into account the user’s timezone.
Localization (“l10n”), on the other hand, is the process of preparing the content of the app to be available in different languages. This includes translating most of the app’s resources, like texts, images, and sounds. Resources for different languages are usually kept in different files or directories, and the OS chooses the right one based on user settings.