Building a mobile app has become a top priority for many companies. However, it’s often difficult to choose a development approach as the lines between the various options are becoming increasingly blurred. In our recent post, A Guide to Mobile

 App Development: Web vs Native vs Hybrid, we broke down the three options and outlined the pros and cons for each. This article will dive deeper into Native Mobile App Development and the benefits of choosing this particular development approach.

What is Native Mobile App Development?

Native mobile app development involves building apps for specific mobile operating systems. Users can then access them from dedicated app stores (such as the App Store or Google Play). If you intend to build an application for iOS, app developers will use programming languages Objective-C or Swift. In contrast, developing for Android calls for the programming languages Java or Kotlin.

Both Apple and Google provide app developers with their own development tools, interface elements, and software development kits (SDKs). Most companies will invest in native mobile app development because of the benefits offered in comparison to other types of apps such as hybrid or web. As mobile software is becoming a necessity, it’s important for companies to be well-informed about the pros and cons of each app development approach. Here are the key benefits of native mobile app development:

5 Benefits of Native Mobile App Development

1. Native Apps Have The Best Performance

With native mobile app development, the app is created and optimized for a specific platform. As a result, the app demonstrates an extremely high level of performance. Native apps are very fast and responsive because they are built for a specific operating system and are compiled using the platform’s core programming language and APIs. As a result, the app is much more efficient. The device stores the app which allows the software to leverage the device’s processing speed. As users navigate through a native mobile app, the contents and visual elements are already stored on their phone. This results in quick load times.

2. Native Apps Are More Secure

Web apps rely on different browsers and underlying technologies such as JavaScript, HTML5, and CSS. Developing a native mobile app is a great way to guarantee your users reliable data protection.

3. Native Apps Are More Interactive And Intuitive

Native mobile apps run more smoothly, especially when it comes to user input and output. These types of apps inherit their devices’ OS interfaces, which makes them look and feel like an integrated part of the device.

The biggest benefit to native mobile apps is the superior user experience. Because native apps are created for a specific operating system, they can stick to guidelines that enhance and align the user experience with the operating system. As a result, the flow of the app is more natural. Adhering to specific guidelines eliminates the learning curve and allows users to interact with apps using actions and gestures they’re already familiar with. 

4. Native Apps Allow Developers to Access the Full Feature Set of Devices

Since native apps are developed for their particular platform, they take full advantage of the software and the operating systems’ features. These apps can directly access the hardware of the device, such as the GPS, camera, microphone, etc. That means they offer faster execution, which ultimately results in better user experience.

Push notifications are another huge advantage to choosing native app development. Push notifications go through the iOS server (APNS) which means you need your app bundle ID. The same goes for Google’s Cloud Messaging (GCM).

5. Native App Development Tends to Have Fewer Bugs During Development

It’s much more difficult to maintain two different applications in one codebase than it is two applications in two codebases. With native app development, you have fewer dependencies for bugs to occur. This is because you’re not relying on a cross-platform tool such as Xamarin or Cordova. Hybrid apps access hardware through a bridge which often slows development down and can amount to a frustrating user experience.

This problem is prominent when new versions of Android and iOS are released. Native app developers have access to new SDKs. This means they can start building their applications with the most recent features. Because of this lead time, users of native applications have access to new platform features the moment they update the operating system. 

With hybrid app development, developers are dependent on a cross-platform development tool such as Xamarin or Cordova. Every time new features are released in the UI kit, you need to wait for the tool to support it. When you develop a hybrid app, there’s an added layer that you don’t have control over which can increase the chances of bugs occurring. Bugs are a huge concern for hybrid app development when working with the latest features that have been released for a particular operating system. This is an essential and often overlooked part of generating loyalty among users.

Other Native Mobile App Development Considerations

Although the initial cost may be higher with native mobile app development, you’ll save time and money in the long run by doing it well the first time. With a great user experience, better performance, and the ability to leverage device features, you’re able to offer your users a more personalized and rewarding experience in the long-term. The combination of native mobile app advantages will result in higher conversion rates and will ultimately boost customer loyalty.

Related: The Definitive Guide to Mobile App Development Costs [Infographic]

The Ultimate User Experience

Technical and functionality shortcomings aside, non-native apps cannot compete with the responsiveness and user experience of the native approach. If a business intends their app to be a central tool for interacting with customers and stakeholders, it must deliver an excellent user experience that supports mobile app retention. Dissatisfaction, even in the slightest, can lead to poor retention rates and high uninstallation.

Native app development gives developers considerably more control over the user experience. What’s more, it allows them to design their apps for easy support. We believe it’s best to stick with native and not sacrifice the design elements that are unique to each platform.

Final Thoughts

While the discussion to differentiate the three mobile app development approaches will continue, it’s important to remember that you shouldn’t choose an approach for the technology, but rather, choose based on your app’s functionality. If you choose an approach that doesn’t allow your app to utilize device features, for example, then you’ll end up wasting a lot of time and money when you decide to add these features later. To decide which development approach to take, ask yourself these key questions:

1. How important is the performance of your app?
2. Does your app need to include any device-specific features?
3. Do you want your app to support multiple platforms and devices?
4. What is your mobile app development budget?

Keep Reading:

• 4 Essential Success Criteria For  Mobile Product Development
• Mobile App Design: Designing For A Web App Vs. Native App
• [Infographic] A Guide to Mobile App Development: Web vs Native vs Hybrid

Apple’s WWDC 2020 came to a close last week. Although this year’s event was a little different (digital-only), several new updates announced during this year’s keynote will undoubtedly shake up mobile app development. 

Here’s what you need to know:

iOS 14

As has become customary at these events, Apple unveiled its latest mobile operating system – iOS 14. This year’s emphasis is on personalization and convenience. Specifically, the introduction of new widgets, and App Library, some argue that Apple is doing better than Android, long known for its ability for users to personalize. 

The first update to the iPhone operating system is its App Library, which automatically sorts and categorizes apps on a user’s phone based on their function. It puts your most-used apps in an easy-to-navigate view. For example, Facebook and Twitter would list under a social media tab while Apple TV+ and Netflix will list under entertainment.

Users will now have more options for widgets and will be able to freely move them around the iOS 14 home screen to personalize it according to their needs. One of the widgets Apple introduced during the event was the Smart Stack, which is basically a stack of multiple swipeable widgets in one and even intelligently curates them according to the time of the day.

Other updates include picture-in-picture functionality for video, an improved Apple Maps with a special view for cyclists, and a Translate app that works in real-time. 

Apple Ditches Intel

In a significant decision, Apple CEO, Tim Cook announced that Apple would stop using the Intel processors that have long powered Macs and roll out computers made with ARM-based Apple Silicon chips for Macs. The first Mac computers with Apple chips will be released later this year as a part of a transition that is expected to take about two years. The switch is meant to make Mac devices more energy efficient, ensuring better performance and battery life.

Mac computers will be able to run apps made initially for the iPhone and iPad. Developers will be able to develop apps that work on all Apple hardware. Apple’s new operating system, Big Sur, was built for integration with the latest processors to allow for a smooth transition. Apple computers had used Intel processors for the last 15 years.

HomeKit

Apple’s smart home platform will utilize facial recognition software, allowing users to see who’s at the door through their smart doorbells and cameras. Users can also adjust the lighting in their homes. Apple touted security, noting that its Home App and HomeKit utilize end-to-end encryption to protect customers.

Apple is partnering with Amazon, Google, and other tech leaders to set up a smart home network, enabling easier use of this innovative technology.

watchOS7, tvOS 14, and macOS Big Sur

watchOS7: Most of the watchOS7 updates, like the iOS14 updates, were focused on personalization with providing users with the ability to now create their watch faces and share them with other users. 

The most anticipated announcement, however, was the introduction of long-awaited sleep tracking capabilities to the watch. The new watchOS sleep tracking features include a Wind Down mode, which helps you go to sleep by setting your desired bedtime, wake-up time, and setting your screen to Do Not Disturb. 

Additionally, the latest update will introduce a hand wash timer that tracks how long you wash your hands by counting down with you. 

tvOS 14: With the latest updates, Apple seeks to create a more immersive experience for gamers. With the tvOS 14 updates, Apple has expanded Xbox controller support to work with Xbox Elite 2 and Xbox Adaptive controllers, making the gaming experience incredibly immersive. Additionally, they have introduced a new multi-user feature for Apple Arcade. Users playing games on their iPhones or iPads can continue their Apple Arcade games on their Apple TV, right from where they left off.

macOS Big Sur: The OS includes updates to major apps like Safari and Guide, with Apple claiming a 50% increase in the speed of the upgraded browser. Safari also comes with even better tab management, making it a smoother experience altogether. Additionally, the new OS includes a familiar notification and action center to that of iOS 14 with customizable widgets. 

Right now, Apple’s macOS Big Sur is available for MacBook (2015 and later), MacBook Air (2013 and later), MacBook Pro (late 2013 and later), Mac mini (2014 and later), iMac (2014 and later), iMac Pro (2017 and later) and the Mac Pro (2013 and later).

AirPods get a serious update

AirPods Pro will get spacial-audio using directional audio filters, based on where you and your device are positioned, to give a surround sound experience from two earbuds. Spacial-audio is compatible with 5.1, 7.1, and Dolby Atmos. The new firmware update will also enable automatic switching, creating a seamless transition when playing audio on one device and switching over to another (i.e., MacBook to iPad). 

How does WWDC 2020 Impact Mobile App Development? 

One of the most significant announcements is the new user privacy features that will be bundled in with the iOS 14 update. Starting with iOS 14, apps will need to receive permission from users to use the Identifier for Advertisers, the IDFA, which explicitly grants permission to track users across apps and services. 

On top of that, it has also been revealed that the App Store product will start to feature summaries and a tailored breakdown of your self-reported privacy practices, plus a link to your privacy policy. The depreciation of the IDFA has been long anticipated, and it seems that Apple has taken the first steps to give users more power to opt-out of tracking. With greater visibility and control to enforce restrictions on the part of the user, this could hugely impact your users’ view and behaviors, including your targeted advertising efforts and even integrating third-party SDKs in your app.

This is a clear prompt for developers to converse with users to gain tracking permissions and to clarify the value exchange in granting these permissions to their users. More than ever, developers and businesses need to reimagine the app experience through new formats for app discovery and user acquisition.

Apple Pay launched in 2014 as the first mobile wallet, which enables people to connect credit cards, debit cards, and bank accounts to mobile devices to send and receive money. Out of the cornerstone mobile wallet services today (Google Pay, Samsung Pay, and Apple Pay), the Apple wallet remains the largest, claiming 34 percent of the market share.

This article offers an overview of Apple Pay, how it works, the market outlook, and reasons you should consider integrating the payment service in your mobile application. 

What is Apple Pay?

Apple Pay is a mobile wallet service that facilitates mobile payments or regulated transactions from an iOS device. Apple Pay works on the iPhone (version 6 or newer) and the Apple Watch and Mac operating systems. To make a payment with Apple Pay, users add credit cards, debit cards, or prepaid cards to the Wallet app on their device, which allows them to make contactless payments in stores, in apps, on the web, or anywhere an Apple Pay badge is present. To complete payments, users can use Face ID, Touch ID, or a passcode to authenticate the purchase. 

Is Apple Pay Secure? 

Apple Pay allows users to make frictionless, secure, and private transactions. Specifically, Apple Pay leverages security features built-in to the hardware and software of iOS devices to help protect transactions. Apple doesn’t store or even have access to a user’s original credit, debit, or prepaid card information. Apple doesn’t save any transaction history, either. When a user adds their banking credentials, Apple decrypts the data, determines the card’s payment network, and re-encrypts the data with a key that only the user’s payment network, bank, the bank’s authorized service provider, or card issuer can unlock. 

To securely transmit payment information when a user makes a purchase in an app or on the web, Apple Pay receives the encrypted transaction and re-encrypts it with a developer-specific key before the transaction information is sent to the developer or payment processor. This key ensures that only the app or website the user is purchasing from can access the encrypted payment information. Additionally, websites are required to verify their domain whenever they offer Apple Pay as a payment option. 

The Apple Pay Market Outlook

According to eMarketer, Apple Pay’s dominance, as well as the increase in retailer adoption of proximity payment technology, is driving transaction volume in the United States. eMarketer estimates that proximity mobile payment transactions will total $98.88 billion in 2019, growing 31.8 percent to $130.36 billion next year. By 2021, the total transaction value will reach $161.41 billion.

Much of this growth is a credit to Apple Pay, which currently captures the largest share of the proximity mobile payment market in the United States. Additionally, this is the first time a universal mobile payment app has surpassed the Starbucks mobile app, which had long led the category despite being specific to one retailer. Apple Pay became the market leader last year when 27.7 million Americans used the app to make a purchase.

User adoption of mobile proximity payments is also witnessing favorable projections. As of 2019, there are 441 million Apple Pay users worldwide.

Source: Statista

Further research estimates that roughly 80 million U.S. users will access mobile payments in 2023, up from 69.4 million in 2020. 

Where and how consumers make purchases has dramatically evolved—from walking into a store to shopping online using smartphones, tablets, and wearable devices. Connected devices and the commerce they enable are becoming increasingly integral to consumers’ willingness to pay for purchases. As Apple Pay continues to grow in popularity, there are plenty of reasons to integrate the payment option into an app. Many colossal brands from Airbnb, Etsy, Ticketmaster, Target, Lululemon, and countless others have already made Apple pay an opportunity for consumers. Let’s look more closely at the reasons Apple Pay is a smart integration for a mobile app. 

Three Reasons You Should Offer Apple Pay in Your App

1. Consumers Have New Shopping Behaviors

Connected devices give consumers the freedom to shop anytime, anywhere — and now while doing anything. Convenience and saving time drive those behaviors, allowing consumers to “multitask commerce” as part of their everyday lives. A research study from PYMNTS, in collaboration with Visa, discovered that respondents reported making purchases while carrying out daily activities like commuting, cooking, and even exercising, many doing so while using connected devices such as smartphones, tablets, computers, wearables or voice-activated devices. In fact, across the group of respondents, more than three-quarters of consumers (76 percent) made purchases during at least one of their everyday activities, every day. 

Most impressive is the very long tail of activities that defines the connected consumer’s daily journey. PYMNTS found that no one consumer follows the same path, though there are some common threads: making purchases while paying bills (39 percent), eating lunch (34 percent), eating dinner (27 percent), and browsing the internet (33 percent). Connected commerce creates an environment of serendipity for consumers — shoppable moments, whatever the device, whatever the time and whatever a consumer happens to be, and sellable moments for merchants.

2. The Home is Now a Commerce Hub

Devices that connect to the internet give consumers more options to do things at home that they once could do only while away from it. Connected devices also make “going shopping” at a store that consumers can choose to but don’t have to buy things. 

Connected devices not only give consumers more opportunities to make purchases during the course of their day-to-day activities, but also give consumers more options to do so while at home. Specifically, purchasing while watching TV has increased by 19 percent (from 12.2 percent to 14.5 percent), while eating dinner has increased 4.9 percent (from 14.4 percent to 15.1 percent) between 2018 and 2019.

3. Extend the Value of Your Loyalty Programs 

Most customers will not download a brands’ mobile apps, so business owners and marketers need to smartly leverage the mobile ecosystem to borrow mobile moments from the popular apps that their customers already use every day. Mobile Wallets and such apps.

A consumer can still use Apple Wallet even if they’re not using Apple Pay to make purchases. Brands can leverage Apple Wallet by creating Passes for loyalty cards. Passes are digital representations of information that might otherwise be printed on small pieces of paper or plastic. They let users take action in the physical world. Passes can contain images and a barcode, and passes can be updated at any time. A user views and manages their passes using the Wallet app. Passes can be used to check-in for flights, get and redeem rewards, get into movies, or redeem coupons. Passes can include useful information like the balance on your coffee card, membership tier and points, your coupon’s expiration date, your seat number for a concert, and more.

Final Thoughts

It is increasingly clear that, for many consumers, connected devices’ primary benefit lies in their ability to provide secure, ubiquitous, and universal access to retail goods and services, anywhere, anytime and now while doing anything. The future belongs to brands that can create use cases so compelling that consumers barely even notice that they’re engaging in commerce while using them at all. Apple Pay integrations will play a massive role in this shift by creating seamless checkout experiences and simplifying the purchase path. 

A UICollectionView is a way of arranging a content grid or a list of subviews (UICollectionViewCells) in a scrollable view. Collection views are ubiquitous: Instagram’s Search page, Chrome’s tabs overview, or your Favourites lists on media streaming services like Netflix and Crave. All of these examples use a UICollectionView to display cells.

For this article, I’ve been working with Clearbridge Mobile iOS Developer, Conor Masterson, to learn about collection views and resolving the issue of code clutter that sometimes happens when recycling UICollectionViewCells. This post will specifically explore how to implement a protocol for brevity in collection view code. Credit goes to Conor for writing the sample application that goes along with this article. If you’d like to look at the full configuration code, there is a GitHub link at the end of the post.  

UICollectionView Structure

Before we dive into avoiding cell verbosity, let’s breakdown the structure of a UICollectionView. There are two central collection view components: UICollectionView and UICollectionViewCells.  

1. UICollectionView: the focal view displaying cell content, which is comparable to a UITableView. Much like a table view, a collection view is a UIScrollView subclass.   
2. UICollectionViewCell: Again, this component is like a UITableViewCell in a table view. These cells display content and are subviews within the collection view.

iOS applications need to know what cell type is designated to a given position in the collection view. It’s up to the programmer to provide an instance of that cell type, set it up and then hand it back to the collection view.

Recycling Cells in UICollectionView

Collection views can hold 1000 (or more) items. That’s a lot of cells to hold in memory, so iOS nixes that idea. iOS applications hold just enough cells to supply the content visible on the screen and use a small buffer so when a user scrolls, additional content is ready immediately. UICollectionView recycles the cells that move off screen for the new cells a user sees as they continue scrolling.

When the collection view needs a new cell, a programmer needs to figure out what cell type is necessary and prompt the collection view to provide an instance of that type. The collection view handles if it can recycle an old instance or create a new one for the programmer to use.

Cell recycling looks something like this:

Let nextCell = collectionView.dequeueReusableCell(withReuseIdentifier: "Cell Reuse Identifier", for: requestedIndexPath)

Cell Verbosity and Overcomplexity

For the collection view to know what cell relates to “Cell Reuse Identifier,” we have to register the cell with the collection view.

collectionView.register(UINib(nibName: "Cell Nib Name", bundle: nil), forCellWithReuseIdentifier: "Cell Reuse Identifier")

The example above has to be written for every cell type.

collectionView.register(UINib(nibName: "Cell Nib Name A", bundle: nil), forCellWithReuseIDentifier: "Cell Reuse Identifier A")
collectionView.register(UINib(nibName: "Cell Nib Name B", bundle: nil), forCellWithReuseIdentifier: "Cell Reuse Identifier B") 
collectionView.register(UINib(nibName: "Cell Nib Name C", bundle:nil), forCellWithReuseIdentifer: "Cell Reuse Identifier C")

It gets ugly quick; however, a solution is to write code that allows you to do this instead:

collectionView.register([TypeACollectionCell.self, TypeBCollectionCell.self, TypeCCollectionCell.self])

Registering cells this way is a lot neater and easier to read. It removes the literal strings (“Cell Reuse Identifier A”), and if you have to change a reuse identifier, you only have to make the change in two places – opposed to two-plus (wherever it’s used) places.

Cleaning Up a UICollectionView with a Protocol

To remove some of the clutter, the first thing to do is define a Protocol. The protocol we need to define for this exercise is pretty simple:

Protocol RegistrableCell: UICollectionViewCell { 
	static var nibName: String { get }
	static var reuseIdentifier: Strong { get } 
}

This protocol is called RegistrableCell. It can only be applied to UICollectionViewCells and their descendants. It contains two properties: nibName and ReuseIdentifier. Both properties are strings that you can retrieve the value of, but not change.

Next, the collection view cell types need to conform to the protocol. Let’s use TypeA as an example:

class TypeACollectionCell: UICollectionViewCell, RegistrableCell { 

	static var reuseIdentifier: String {
		return "TypeACollectionCell"
	}
	static var reuseIdentifier: String {
		return "TypeACollectionCell"
	}
}

The strings are static because they’ll never need to change while the app is running and we need to be able to read them before we create an instance of TypeACollectionCell. This code is written for each cell type in the UICollectionView.

Finally, we need to let the collection view register RegistrableCell types, which requires us to extend UICollectionView.

extension UICollectionView { 
	func register (_ nib:RegistrableCell.Type) {
		self.register(UINib(nibName: nib.nibName, bundle: nil), 
forCellWithReuseIdentifier: nib.reuseIdentifier) 
	} 

	func register(_ nibArray:[RegistrableCell.Type]) {
		nibArray.forEach {
			self.register($0)
		}
	}
}

In the first function, we declare a RegistrableCell and it uses the strings defined in the protocol so the collection view registers normally. The second function takes an array and leverages the first function to register all the cells in that array.

Code quality is an essential property of successful software products. Finding logical ways to improve brevity improves the readability of your code, which in turn raises code quality overall. Well-written code avoids overcomplexity to reduce risk so changes, maintenance, and adjustments require little effort for the programmer. Using a protocol to register and recycle cell types is a smart way to write clean and highly readable collection views.  

You can find the sample application on Github, here.

What do you do once you decide that developing an app is the right solution your brand needs to resolve a core business problem? Well, when you begin planning your technical requirements, you need to decide what platform you want to develop on, but how do you decide which platform is right for your product?

With iOS and Android owning 97 percent of the global mobile market share, the ideal approach to mobile app development is to build and launch for both platforms. However that’s not always possible – constraints like time, budget, and resources can prevent you from developing for both OSs at once. Instead, you may want to consider launching on one platform first and then introduce a second platform at a later date.

Each platform has distinct advantages, so it’s important to do enough research to understand which OS properly aligns with achieving your product goals.

Haven’t set your product goals? Learn more about how a Design & Discovery workshop establishes a user-focused product vision and measurable success criteria to boost ROI. Talk to a mobile expert, today.

This article is a comparative guide examining both iOS and Android in four key areas: audience, monetization, project timeline, and budget to help you decide whether iOS or Android is the right choice for your product.

Audience

Right away, the differences in the users iOS and Android attract are noticeable. To choose your ideal OS, you need to define what end goal your app aims to achieve and which audience is important to your business model.

Android has the greatest global market share sitting at around two-thirds and gets more app downloads than iOS. Sensor Tower reports that the Google Play Store pulled in approximately 75.7 billion first-time app installs worldwide in 2018. Comparatively, the App Store only drove 29.6 billion. While Android might rake in more downloads, iOS users tend to exhibit higher engagement rates and spend more on apps and in-app purchases.

Also, Android witnesses a lot of popularity in lower-income and developing countries, while iOS users tend to live in North America and Western Europe. iOS users are also typically younger with higher incomes and more education.

Monetization

Your monetization strategy plays a large role in determining which platform to develop for first. Each OS lends itself well to opposing monetization strategies. From a revenue standpoint, it’s a well-known fact that iOS apps make more money. Even though Apple has fewer users and generates fewer app downloads, the App Store brings in much more revenue. At the end of 2018, Apple’s App Store generated about 88% more revenue than the Google Play Store. If intend to monetize through a subscription model or in-app purchases, iOS is the more lucrative platform. On the other hand, Android apps tend to monetize successfully with an ad-based model.  

Despite iOS’s significant lead in revenue, the Google Play Store did see an increase of 27.3 percent in consumer spend year-over-year.

Project Timeline

How quickly do you want to get your app to market? Your timeline can play a huge part in determining what platform is best to develop for first. Developing for Android generally takes more time due to longer release cycles and device fragmentation. Building an app that is compatible with multiple Android devices generally takes more time: there are thousands of Android devices which have a variety of screen sizes and OS versions running.

Even though Apple owns all the hardware and software, and there are far fewer iOS devices than Android devices, iOS devices are becoming less standardized than they have been in the past. Since the introduction of the iPhone X series, developers now have more screen sizes and UI constraints to work around.

While building for iOS can sometimes be quicker, it can also take longer for the App Store to approve your product with the strict regulations and quality expectations in place. In contrast, Android apps typically take a day or two to get approved and updates can be pushed within a matter of hours.

Budget

The cost of mobile app development comes down to the scope and complexity of the project; the larger and more complex a project is, the more it is going to cost. There is nothing inherent to either iOS or Android development that makes one more expensive than the other.

With that said, if you are aiming to cover a large number of devices and OS versions, apps will require more time and resources, and thus incur higher costs. If the scope is more aligned with supporting an equal number of devices and OS versions on iOS and Android, the cost of development will be similar.

Making The Decision

Ultimately, your decision to build for iOS or Android first is going to come down to what works for your business.  

If your target user is North American, higher income, and you plan to monetize from in-app purchases, you likely want to go with iOS first. If you’re aiming for a broader, global market and plan to monetize through advertising, Android may be the better bet.

Is there another option?

In some cases, a web app can be the best option for your business. Web apps are essentially websites that look like native apps, but they don’t take up any storage on a user’s device. A major advantage of web apps is you can develop one app for both iOS and Android platforms as long as it can run in a web browser like Chrome, Safari, or Firefox. Web apps are an inexpensive option compared to native development, they’re easy to build and relatively easy to maintain. However, in most cases, web apps are far less interactive and intuitive than native apps and cannot leverage device hardware or utilities.

Again, choosing the right platform for your mobile app depends on the app content you intend to create and overall business goals. It comes down to looking at your target market, as well as core user demographics and choosing the option that best fits your business.

Can’t decide whether you should choose native development or web development? Read our Guide to Mobile App Development: Web vs. Native vs. Hybrid to learn more about what approach best suits your mobile strategy.

How well do you know your target users? What types of apps are they likely to download? What is their willingness to pay for apps and make in-app purchases? The answer to these questions will vary depending on which mobile OS your users prefer. Understanding how behaviors differ between Android and iOS users will help you to identify which user group is the most suitable for your product and business goals, and ultimately help you choose which platform is right for your mobile app development project.

By looking at your users’ choice of smartphone, you already gain some useful knowledge from statistical data alone. For example, iOS users typically have a higher income and more education than Android users. This information in itself may influence your decisions about the product’s monetization strategy. If your monetization strategy relies heavily on in-app purchases, an iOS app may be the most profitable platform; however, if you plan to monetize through ad placements, Android might be your best choice.  Remember, the primary objective of any mobile app is to provide users with a solution to a specific problem they collectively face. If you don’t have a solid understanding of how user behavior changes between OSs, you’ll find it difficult to develop an app that addresses the specific needs of your target user group.

Do you need help transforming your business strategy into a product strategy? Are you sure you’re making the right platform choice? Talk to one of our mobile experts about how a Design & Discovery Session helps identify which platform your audience is using. Start a conversation.

With both Android and iOS accounting for over 97 percent of the mobile market share worldwide, brands that are looking to develop an app will have to seriously consider both platforms, but in most cases, pick one or the other due to project constraints like time and budget. Below are some differences between Android and iOS user behavior to help make choosing a platform easier.

Device Compatibilities

There are some key differences between Android and iOS devices that impact the user experience and influence the reasons you might choose one over the other.

For example, Apple is known to uphold a strict set of regulations for app submissions to the App Store, whereas Android developers have a lot more freedom when it comes to developing apps and submitting them to the Play Store. While an iOS app may take longer to develop and pass the verification process, a more consistent, secure and intuitive app experience is generally the result – something loyal iOS users praise about the OS. Android users, on the other hand, will vouch for the customizability and freedom their devices allow, which enables them to truly tailor their phone to their needs and desires.

User Demographics

Currently, Android holds the largest global market share at over two thirds. This is mainly due to the popularity of the Android OS among lower-income and developing countries. iOS, on the other hand, is more prominent in North America, UK, and Japan among those with higher income levels, and education. Studies also suggest that iOS users generally have higher app engagement and tend to spend more money per app.

A survey by Slickdeals points out that iOS users make an annual income of $53,231 USD compared to $37,040 USD for Android users. The survey also shows that iOS users tend to spend more, particularly on items relating to self-image such as clothing and cosmetics. This can relate to the fact that iOS devices are slightly more popular amongst women and Android devices are slightly more popular amongst men.

In a 2018 mobile gaming apps report by Liftoff, the data shows that in-app purchase conversion rates for women were 26 percent higher than for men. Insights on location, income, and purchasing decisions can directly impact engagement actions like in-app purchases and subscription enrollment, which you should consider when planning your monetization strategy. These demographic differences also have influence over which types of apps a user is likely to download altogether.

Consumer Spending Behaviour

Figuring out how each OS user is likely to pay for an app or pay for in-app purchases is critical. While global app revenue grew by 23 percent in 2018, there is indeed a gap between how much an Android user will spend on an app and how much an iOS user will spend on an app.

According to app analytics firm, Sensor Tower, Apple’s App Store generated $46.6 billion USD, while the Google Play Store made only half of Apple’s profit at $24.8 billion USD – a difference of 88 percent by the end of 2018

The typical iOS user is also more likely to spend more on clothing and cosmetics than their Android counterparts which reflects on the types of apps they prefer. These insights are very valuable to brands looking to develop retail apps or generate revenue from paid apps. In contrast, Android apps rely on mobile advertising as the main source of revenue.

App Retention and Engagement

Android and iOS users tend to use their devices in terms of viewing and engaging with content very differently. iOS users earn themselves the title of “power users” due to simply engaging with more content on their devices for a longer period of time.

According to a survey by Slickdeals, iOS users on average spend 4 hours and 54 minutes per day on their phone, whereas Android users spend 3 hours and 42 minutes. iOS users also have a faster open speed when it comes to notifications. According to a report by Leanplum, Android users take an average of 48 minutes to open notifications while iOS users take roughly seven minutes.

With that said, Android does have a greater number of media users and a larger audience. Android users tend to prefer utility, performance, productivity, and anti-virus apps. Android users are five times more likely to spend money than iOS users on apps that fall into any of those categories.   

The performance of certain goals like registration, reservation, purchase, in-app purchase, and subscription vary between iOS and Android. In terms of user engagement metrics, iOS surpasses Android in all of these categories, except for registration, in which Android only has a minor advantage.

Which Platform Should You Choose?

When deciding what platform is best for your mobile app, a key question to ask is: what is the goal and purpose of your application? Is the sheer volume of users the main identifier of success for your app, or is your focus on driving engagement? Choosing the appropriate platform will depend on the goal you’re trying to achieve and how you plan to monetize your mobile app.

The perfect scenario would be to develop your app for both Android and iOS to attain the widest and most diverse user base; however, this is not always feasible. While each platform offers unique advantages and characteristics, understanding the differences between the users of each OS can help you make informed decisions about where to focus your efforts to achieve the most business value.

Let’s talk about view controllers. Right off the hop, stop making a mess of your view controllers and start putting your code in logical places – view controllers are for views, and views only. It’s very tempting to throw all sorts of logic into a view controller, but when we separate concerns, we write code that’s easier to understand and easier to reuse.

There are handfuls of responsibilities we can dump into a view controller: data fetching, data transformation, user input, model-view binding, model mutation, animations, and navigation flow, just to name a few. But, we shouldn’t house all of these responsibilities in one place; otherwise, we’re working with a confusing and unwieldy view controller.

This article will focus specifically on navigation and provide an actionable example of using a coordinator pattern to extract navigation flow from view controllers. This article will also touch on how protocols facilitate more concise communication between objects.

For this exercise, I teamed up with Clearbridge Mobile iOS Developer, Michael Voline, to learn about separating concerns to create clean, isolated, and reusable view controllers. Credit goes to Michael for writing the code to support this article. If you’d like to skip the step-by-step example, and move right to the full version of the configuration code, there is a GitHub link at the end of the article.

Note: There are several ways you can decouple view controllers; however, using a coordinator pattern to handle the navigation logic that doesn’t belong in a view controller is one of many ways to create abstractions and separate concerns.

Don’t Let View Controllers Know About Other View Controllers

A problem that sometimes comes up when creating view controllers is writing the code in such a way that one view controller must be aware of another. What’s worse is that when view controllers are aware of the position of other view controllers in an app’s flow, they have the authority to configure and present other view controllers. What ends up happening is view controllers get tied together in a chain and the navigation flow is spread across multiple objects.

What if we need to insert more screens into the flow? We would have to write more configuration code inside the view controllers, further perpetuating the problem.

Coordinators in Action

So, let’s jump in with a solution — if we control the app’s flow with a coordinator pattern, view controllers communicate only with the coordinator and not with each other.

The following examples will demonstrate a coordinator pattern that handles the navigation between two very basic view controllers: a login view and sign-up view. Our login view will present the user the option to sign-up and our sign-up view will present the user the option to go back to the login view. For flexibility, we’ll use protocols to set the communication rules for the coordinator to conform to.

First, we’ll set up a Coordinator to control the app’s flow in the app delegate like this:

@UIApplicationMain
final class AppDelegate: UIResponder, UIApplicationDelegate {

    private let coordinator = AppCoordinator()
    
    func application(_ application: UIApplication,...) -> Bool {
        coordinator.start()
        return true
    }
}

Next, let’s write the view controllers for our login view and sign-up view. Here’s the LoginViewController:

protocol LoginViewControllerCoordinatorDelegate: AnyObject {
    func didPressSignupButton()
}

final class LoginViewController: UIViewController {
    
    weak var delegate: LoginViewControllerCoordinatorDelegate?
    
    @objc func didPressExitButton() {
        delegate?.didPressSignupButton()
    }
    
    override func viewDidLoad() {
        super.viewDidLoad()
        let button = UIButton()
               button.addTarget(self, action: #selector(didPressExitButton), for: .touchUpInside)
              view.addSubview(button)
    }
}

Notice how we’ve set up a LoginViewControllerCoordinatorDelegate protocol. This will help us limit exposure to the AppCoordinator’s methods, which you will see soon.

And, the SignupViewController:

import UIKit

protocol SignupViewControllerCoordinatorDelegate: AnyObject {
    func didPressLoginButton()
}

final class SignupViewController: UIViewController {
    
    weak var delegate: SignupViewControllerCoordinatorDelegate?
    
    @objc func didPressButton() {
      delegate?.didPressLoginButton()
    }
    
    override func viewDidLoad() {
        super.viewDidLoad()
        let button = UIButton()
        button.addTarget(self, action: #selector(didPressButton), for: .touchUpInside)
        view.addSubview(button)
    }
}

From here, I’d like to draw your attention to the protocols in each view controller.

protocol LoginViewControllerCoordinatorDelegate: AnyObject {
    func didPressSignupButton()
}

What we’ve done here is designed a protocol that limits what the LoginViewController has access to in the Coordinator. There are multiple methods and properties inside the Coordinator that the LoginViewController doesn’t need to know; it only needs to know the didPressSignupButton function.

Similarly, we’ve designed a protocol for the SignupViewController, that again limits the information the view controller can extract from the Coordinator. The SignupViewController only needs to know didPressLoginButton function and nothing else.

protocol SignupViewControllerCoordinatorDelegate: AnyObject {
    func didPressLoginButton()
}

By conforming the Coordinator to each of these protocols, we are able to define exact communication rules about what information needs to be conveyed between the Coordinator and our view controllers.

Our app coordinator will look something like this:

final class AppCoordinator {
    
    private let window: UIWindow
    private let navigation: UINavigationController

    // Please see sample project at the end for full implementation.
    // init() {...}

    func start() {
        let login = LoginViewController()
        login.delegate = self
        navigation.pushViewController(login, animated: true)
    }
}

// MARK: - LoginViewControllerCoordinatorDelegate
extension AppCoordinator: LoginViewControllerCoordinatorDelegate {
    func didPressLoginButton() {
        navigation.popViewController(animated: true)
    }
}

// MARK: - SignupViewControllerCoordinatorDelegate
extension AppCoordinator: SignupViewControllerCoordinatorDelegate {
    func didPressSignupButton() {
        let signup = SignupViewController()
        signup.delegate = self 
        navigation.pushViewController(signup, animated: true)
    }
}

The AppCoordinator class contains a navigation property that is used to push and pop view controllers from the navigation stack. In this example, we do not use storyboards and hence we configure window manually (we’ve included a GitHub link for the full version of the configuration code at the end of this article). When we call start() method in AppDelegate, the LoginViewController is pushed onto the navigation stack and the app starts its main flow.

For convenience, we used extensions to conform the AppCoordinator to our two protocols. As you can see, both LoginViewController and SignupViewController propagate touch events to AppCoordinator and let it decide what happens next in the app flow.

We didn’t create a hard-coded path between our login and sign-up views, rather we’ve extracted navigation logic out of the view controllers and placed it into a separate object responsible for transitioning between screens. Following this pattern helps make it easier to see what’s happening in the flow of the app. Using a coordinator also makes testing easier and allows for reusability.

Case and point, each view controller should only know enough to perform its specific action, and nothing else. Save yourself valuable time and effort – keep your view controllers isolated and don’t overcrowd them with code out of convenience

You can find the full configuration code on GitHub here.

Using enumeration or enums to manage state is a useful option to make code less fragile and more robust by replacing state scenarios that shouldn’t be possible with solutions that make them impossible.

Hold up  – how do you end up in a state that shouldn’t be possible?

The Problem with Optionals

Using optionals without adding the additional logic to handle every future state change can lead to states that shouldn’t be possible. Optionals are used in situations where a value may be absent. An optional represents two possible states: either there is value or there isn’t a value at all. Where optionals only represent two possible states, enums are able to specify and combine multiple “stateful” properties into a single state representation.

Let’s clarify using Apple’s example:

class UserAuthenticationController {
	var isLoggedIn: Bool = false 
	var user: User?
}

In the case above, there are opportunities for this controller to enter an “illegal” state. For example, it’s possible for the controller to be in a “logged in” state while the user is nil or non-existent, or vice versa, where the controller is in a “logged out” state when the user exists. Using an optional in this instance forces you to remember to nullify the user manually when entering a “logged out” state. To avoid this, we can capture the properties in a State enum, and make it impossible to enter those “illegal” states:

class UserAuthenticationController {
    enum State {
        case idle 
        case loggedIn(user: User)
    }

    var state: State = .idle
}

Adding a State enum immediately clarifies the controller states with a concrete state list the controller can take on.

Alright, but how exactly do you define an enum?

Using Enums to Manage State

me @ myself

An enum defines a common type for a group of related values. Unlike c enums, which are represented by unique integer values for each case, Swift enums don’t require any primitive raw value. If a raw value is provided for each enumeration case, the value can be a string, a character, or a value of any integer or floating type.

Let me try this. I want to write an enum that filters hockey players for a fantasy draft into a list that matches each player to their position.

I’ll start by introducing my enum type and each enum value using the case keyword:

enum PlayerPosition {
    case leftwing
    case rightwing
    case center
    case leftdefense
    case rightdefense
    case goalie
    case benchplayers
}

I also want each position to match players I’ve chosen for my fantasy draft. I’ll make this happen by using a switch statement for each enumeration case.

func myTeam(for PlayerPosition: PlayerPosition){
    switch PlayerPosition{
        
    case .leftwing:
        print ("Alex Ovechkin, Evander Kane" )
    case .rightwing:
        print ("Nikita Kucherov, Mitch Marner")
    case .center:
        print ("Evgeny Kuznetsov, Patrice Bergeron")
    case .leftdefense:
        print ("Radim Simek, Morgan Rielly" )
    case .rightdefense:
        print ("Kris Letang, Kasperi Kapanen")
    case .goalie:
        print ("Andrei Vasilevskiy, Martin Jones")
    case .benchplayers:
        print ("Auston Matthews, Joe Pavelski, Brad Marchand, Mark Scheifele, William Nylander")
    }
}

Time to check with a professional. And the verdict is…

I’m not wrong, but I’m not right either (It seems I hear that a lot from developers).

me @ developers

In respect to enums, there’s nothing wrong with my first attempt; however, you’re typically not going to have hard-coded lists of data in an app. In a real application, data is likely to be coming from the network or some form of persistent storage.

Using Enums to Force State Integrity

Fine, so I’m not entirely right. Let’s explore how to use enums to manage state and run with this hockey game idea. For the next part of this article, we’ll examine an example of modifying state in a hockey game app, the problems that could possibly arise if State isn’t handled properly, and how to improve the validity of transitions by implementing a State enum. First, let’s set the foundation of our hockey game idea.

To start here are a few simple sketches of what game objects might look like:

protocol Player {}

protocol Team {
    var players: [Player] { get }
}

Above we’ve defined protocols to represent Players and Teams. For this exercise, our Player doesn’t need properties, while our Team provides a read-only list of players.

struct Score: Equatable {
    static let zero = Score(home: 0, away: 0)
    
    var home: Int
    var away: Int
    
    /// Returns a new Score adding the supplied home and away values to this score.
    func adding(home: Int, away: Int) -> Score {
        return Score(home: self.home + home, away: self.away + away)
    }
}

Next, we’ll want our app to keep track of game scores. Above, we’ve built a struct to represent the score of a game consisting of an integer value for each home and away team, and a function to return a new Score by adding the supplied home and away values to the scoreboard.

class Game0 {
    let home: Team
    let away: Team
    var score: Score?
    
    init(home: Team, away: Team) {
        self.home = home
        self.away = away
    }
}

Game0 above, represents the skeleton of a game with a few properties we might want in a game. It’s pretty straightforward: a game has two teams, and if a game is in play, there is a score. You’ll notice we have to declare the score as an optional Score. The score is defined as optional to allow us to distinguish between a game that hasn’t started yet and a game with a 0-0 score.

We can give our game more detail by adding different states. In Game1, we’ll give a game a date once it’s been scheduled, a list of Player stars once it’s over, and four different game states: scheduled, started, finished, or cancelled.

class Game1 {
    let home: Team
    let away: Team
    var score: Score?

    private(set) var date:  Date?        // nil if not scheduled yet
    private(set) var stars: [Player]?    // nil if game hasn't finished

    private(set) var isScheduled: Bool = false
    private(set) var isStarted:   Bool = false
    private(set) var isFinished:  Bool = false
    private(set) var isCancelled: Bool = false

    init(home: Team, away: Team) {
        self.home = home
        self.away = away
    }
}

Now, we’re going to add functions to change game states. In the next example, there are several problems that might arise by calling these functions in unexpected ways.

class Game2 {
    let home: Team
    let away: Team
    var score: Score?

    private(set) var date:  Date?        // nil if not scheduled yet
    private(set) var stars: [Player]?    // nil if game hasn't finished
    
    private(set) var isScheduled: Bool = false
    private(set) var isStarted:   Bool = false
    private(set) var isFinished:  Bool = false
    private(set) var isCancelled: Bool = false
    
    init(home: Team, away: Team) {
        self.home = home
        self.away = away
    }
    
    /// Schedules the game for the specified date.
    func schedule(date: Date) {
        isScheduled = true
        self.date = date
    }
    
    /// Starts the game
    func start() {
        isStarted = true
        score = .zero
    }
    
    /// Ends the game
    func end(stars: [Player]) {
        isFinished = true
        self.stars = stars
    }
    
    /// Cancels the game
    func cancel() {
        isCancelled = true
    }
    
    /// Adds points to the home score
    func homeScored(_ points: Int) {
        score?.home = (score?.home ?? 0) + points
    }
    
    /// Adds points to the away score
    func awayScored(_ points: Int) {
        score?.away = (score?.away ?? 0) + points
    }
}

What happens if a canceled game is started? What happens if a started game is scheduled? Can isFinished and isCancelled be true simultaneously? Should they be able to? In Game3, let’s build a State enum to address the apparent issues we’ve identified in Game2.

class Game3 {
    /// The state of a game
    enum State {
        /// Game has not yet been scheduled
        case tbd
        
        /// Game has been scheduled for `date`
        case scheduled(date: Date)
        
        /// Game is in progress, has scheduled date, and current score
        case started(date: Date, score: Score)
        
        /// Game has been cancelled, date represents the previously scheduled
        /// date, if any
        case cancelled(date: Date?)
        
        /// Game has ended, score represents final score, stars is the list of star players
        case over(date: Date, score: Score, stars: [Player])
    }
    
    let home: Team
    let away: Team
    var state: State = .tbd // start out unscheduled
    
    var score: Score?     { return state.score }
    var date:  Date?      { return state.date  }
    var stars: [Player]?  { return state.stars }

    var isScheduled: Bool { return state.isScheduled }
    var isStarted:   Bool { return state.isStarted   }
    var isFinished:  Bool { return state.isFinished  }
    var isCancelled: Bool { return state.isCancelled }
    
    init(home: Team, away: Team) {
        self.home = home
        self.away = away
    }
    
    func schedule(date: Date) {
        state = state.schedule(date: date)
    }

    func start() {
        state = state.start()
    }
    
    func end(stars: [Player]) {
        state = state.end(stars: stars)
    }
    
    func cancel() {
        state = state.cancel()
    }
    
    func homeScored(_ points: Int) {
        state = state.scored(home: points, away: 0)
    }
    
    func awayScored(_ points: Int) {
        state = state.scored(home: 0, away: points)
    }
}

/// Provide functions for transitioning between game states.
private extension Game3.State {
    var score: Score? {
        switch self {
        case .started(_, let score):    return score
        case .over(_, let score, _):    return score
        default:                        return nil
        }
    }
    
    var date: Date? {
        switch self {
        case .scheduled(let date):      return date
        case .started(let date, _):     return date
        case .over(let date, _, _):     return date
        case .cancelled(let date):      return date
        default:                        return nil
        }
    }
    var stars: [Player]?  {
        switch self {
        case .over(_, _, let stars):    return stars
        default:                        return nil
        }
    }

    var isScheduled: Bool {
        switch self {
        case .tbd, .cancelled:  return false
        default:                return true
        }
    }
    
    var isStarted:   Bool {
        switch self {
        case .started, .over:   return true
        default:                return false
        }
    }
    
    var isFinished:  Bool {
        switch self {
        case .over:             return true
        default:                return false
        }
    }
    
    var isCancelled: Bool {
        switch self {
        case .cancelled:        return true
        default:                return false
        }
    }

    func schedule(date: Date) -> Game3.State {
        switch self {
        case .tbd, .scheduled:              return .scheduled(date: date)
        default:                            return failTransition(for: #function)
        }
    }
    
    func start() -> Game3.State {
        switch self {
        case .tbd:                          return .started(date: Date(), score: .zero)
        case .scheduled(let date):          return .started(date: date, score: .zero)
        default:                            return failTransition(for: #function)
        }
    }
    
    func scored(home: Int, away: Int) -> Game3.State {
        switch self {
        case .started(let date, let score): return .started(date: date, score: score.adding(home: home, away: away))
        default:                            return failTransition(for: #function)
        }
    }
    
    func end(stars: [Player]) -> Game3.State {
        switch self {
        case .started(let date, let score): return .over(date: date, score: score, stars: stars)
        default:                            return failTransition(for: #function)
        }
    }
    
    func cancel() -> Game3.State {
        switch self {
        case .tbd:                          return .cancelled(date: nil)
        case .scheduled(let date):          return .cancelled(date: date)
        case .started(let date, _):         return .cancelled(date: date)
        default:                            return failTransition(for: #function)
        }
    }
    
    private func failTransition(for action: String) -> Game3.State {
        assertionFailure("Attempt to \(action) a game that is \(self)")
        return self
    }
}

In Game2 we added methods that change state (schedule, start, cancel, etc.). When we did this, we opened the door to several issues:

1. None of the state changing methods take into account the current state of the game.
2. We have a number of Bool flags that can conflict with each other (isScheduled, isCancelled, etc.).
3. We have properties that might be populated or nil regardless of the state that the game should be in.

In Game3, we implemented a State enum. The state enum immediately creates safer code by creating a concrete list of states the game might be in. Properties that are only valid in particular states are no longer awkwardly detached from the game, rather they are associated values to the state they are relevant to.

With game properties captured inside our State enum and a well-defined list of states a game can take on, the enum makes our state transitions safe. We have a well-defined list of actions that cause state transitions. These actions are schedule, start, end, cancel, scored and they map onto the state changing methods added in Game2.

The Verdict on Maintaining State

Nothing is stopping you from spreading state across multiple variables. Make your life easier and avoid potential state issues – use enums.

I’d like to give big props to Andrew Patterson, who helped me learn about enumeration and write this article. Thank you, for all your help, patience, and insight: I couldn’t have written this without you. I can’t wait to work on our next project! 

Since 2008, the world has witnessed the App Store revolutionize the way software is bought and sold. This year, the App Store turns ten; in a decade, Apple has built a brand new business ecosystem and opened the doors for countless emerging industries. With the App Store attracting more than 500 million weekly users, the mobile app development industry is stronger than ever and last week’s iOS 12 release reveals some significant changes to compliment last year’s redesign.

The aesthetic changes to the iOS 12 App Store boarder on unnoticeable, but mobile app owners need to keep an eye on the changes to product discoverability in this release. The changes over the past two years are indicative of Apple’s strategic plan to enhance the overall user experience of the App Store. With iOS 11, the strategy focused on making apps easier to find; with iOS 12, Apple makes finding apps personal. Here’s what you need to know.

Personalizing the iOS 12 App Store

If you’re the type of person who pays attention to small details, you may notice the subtle changes to the iOS 12 App Store interface design. For the most part, the design tweaks are largely undetectable. Similarly, many of the content categories will remain the same (noteworthy content, apps and games of the day, developer spotlights – the usual). Additionally, talks were circulating during the iOS 12 beta about a new “You Might Have Missed” tab that limits the amount of top performing content you see from the previous week; however, I have yet to see the change on my device in the official release.

Design decisions aside, the most important change in this year’s App Store update is the elements of personalization throughout the entire store. Personalization is a principal theme in iOS 12; it is evident in many of the native iOS app development features Apple is rolling out in this release.

The concept is simple; iOS 12 personalizes the user experience by giving users content and apps they are likely to be interested in based on data points like previous downloads, purchases, and browsing behavior. As well, personalization is central to many of the new feature additions in iOS 12 like Siri Shortcuts, enhanced machine learning, and push notification content.

What does this mean for mobile app owners?

1. It may be more difficult to land a featured spot in the iOS 12 App Store.
2. Expect your number of App Store impressions to take a hit.
3. Those looking to publish an app need to keep personalization in mind from the first stages of product discovery.

With that, there are several best practices strategies you can put in place to increase the likelihood of your product’s App Store success.

Keep Your App Store Updates Timely

Personalizing the App Store content may make it more difficult to get your app featured in the store, or at the very least, lessen the reach of your product feature.

We recently wrote about the difficulties and benefits of winning a featured placement in the App Store. In short, being a featured app is great for brand identity, awareness, as well as driving conversions; however, earning featured recognition is even better for your product when it appears in a targeted search or a niche category. Your efforts to get a product featured in the App Store will need to combine traditional marketing tactics and elements of personalization for the best results.

To improve your chances of being featured in the App Store, a worthwhile tactic is to schedule your release dates or product updates with each iOS version release. Apple is going to give more consideration to featuring mobile apps that give users a chance to use the new features they’re currently promoting. For example, if you own a QSR app and your most recent update allows users to create a Siri Shortcut to order their most frequent purchases, you improve your chances of getting noticed by Apple. By the same token, if you own a password management or productivity app, leveraging Apple’s new Account Authentication feature is a strategic move to make alongside the iOS 12 release.

Recommended: Top 10 Ways to Get Your App Featured in the App Store

Prepare to See Fluctuating App Store Impressions 

With the release of iOS 12, mobile app owners need to ensure their existing App Store Optimization (ASO) strategy is designed to accommodate App Store personalization. Specifically making sure the strategy puts greater emphasis on the user from their unique pain points, to their search queries, and right down to their aesthetic tastes. Precise and unambiguous user insights are necessary to make sure the right people are finding your product’s App Store listing.

If you haven’t already, it’s time to hone in on your keyword research and targeting. The keywords you decide to rank for will be the pillars of your App Store presence, and it’s crucial to make sure they align with your users’ search queries. Getting the most out of iOS 12’s personalized App Store will require both an ASO and a Search Engine Optimization (SEO) strategy to establish credibility and position your app as a reliable solution to user pain points.

Recommended: How To Use ASO and SEO For Your App Promotion

Revisit Your App Store Listing

Approximately half of the iOS app installs come from App Store Search. If you’re not optimizing your App Store listing for your target audience’s search queries, you’re ignoring a significant promotional opportunity for your product. There are several important fields throughout your App Store listing that require attention including the app’s meta title, meta description, and any other relevant keyword fields.

Your app store listing is the touchpoint in the user journey where the final decision to install your product takes place, with this new trend of extreme personalization, if your App Store listing doesn’t reflect what users are searching for, your user acquisition efforts will suffer.

Think About Personalization From Product Discovery

When you’re building your product strategy and planning product requirements, keep this personalization trend at the forefront of your mind.

Start by asking yourself purposeful questions like, what is the objective of this mobile app? What should the app be able to do, and what features are required to make this functionality possible? It’s unlikely that you will be incorporating personalization in the early stages of your mobile app, but creating a solid vision of how your product will grow will give you a better understanding of how personalization will fit into your strategy down the line.

Participating in Product Discovery will build a foundation for your mobile app to incorporate functionality that truly benefits your core user base. A Design and Discovery phase is orchestrated to set product goals, understand clear business outcomes, and prioritize features for the first stages of your mobile app.

At Clearbridge Mobile, we guide our clients through a concentrated five-day Design and Discovery workshop that is both intensive and collaborative. At the end of one week, participants walk away with key product features, user journeys, wireframes, mockups, and a clickable app prototype. The overall goal is to recognize your product’s success metrics and validate your ideas early on in the development process. Learn more about how Design and Discovery can help you get started on your mobile app project; start a conversation, today.

iOS 12 is here. The new mobile operating system was released last week, and it came with stacks of exciting features for both iPhone users and developers. From enhanced machine learning capabilities, additional Siri skills, and a new approach to notifications, iOS 12 offers new additions for every area of native iOS app development.  

Here’s a list of the most noteworthy features in iOS 12 that will impact mobile app development in 2018.

iOS 12 Introduces Siri Shortcuts

Siri has to be one of the more undervalued voice assistants in rotation today; however, iOS 12 makes Apple’s personal assistant a little more valuable. In iOS 12, Siri becomes more proactive with the addition of Shortcuts. The primary purpose of Siri Shortcuts is to make the voice assistant more useful throughout the day and minimize the number of steps users take to accomplish everyday tasks.

Siri Shortcuts monitors user activity and suggests shortcuts based on normal in-app behaviors. Siri will make suggestions in Siri Spotlight or on the user’s Lockscreen. Users can also add unique voice phrases and search queries to their Siri assistant.

Source

Siri learns and predicts shortcuts for your app through what Apple calls donations. Developers and users can donate shortcuts to add an extra element of personalization to the device. Simplifying user actions with voice technology will quickly become an indispensable part of the iOS experience. Developers will need to react promptly to offer users the simplicity and speed they’re growing more accustomed to every day.

The importance of user segmentation has never been more apparent. In iOS 12, developers will need to have a precise understanding of what in-app actions drive the most engagement and make Siri Shortcut donations for the most frequently used features. Experimenting this new update will also help developers gain a better understanding of what features don’t support their app’s user retention strategy.

Another valuable addition to Siri is the assistant’s ability to handle shortcuts without unnecessarily opening an app. Developers can provide rich user experiences by launching shortcuts in the background of an app and allow users to interact with particular features directly from Siri’s interface. Specific actions – like deep links in Siri – will open the app. It’s it important to be mindful of user expectations. Users will expect the app to handle shortcuts that can’t run in the background to open the app; for example, when the app requires user authentication before completing an action.

All in all, Siri Shortcuts goes a long way towards closing Apple’s digital assistant gap in a market dominated by Google Assistant and Amazon Alexa.

Learn More: 5 Key Benefits of Native Mobile App Development

Core ML 2 and Create ML

Last year, Apple introduced Core ML: a toolkit that makes it easy for developers to integrate machine learning models into their apps including text, barcode, face, and landmark detection as well as object tracking. Core ML is the machine learning framework responsible for Siri, Quick Type, and Camera functions. This year, iOS 12 comes with Core ML 2 which further simplifies machine learning integrations. Now, developers can integrate models with only a few lines of code.

Core ML 2 supports expansive deep learning possibilities and includes over 30 layer types, as well as support for standard layer types like tree ensembles, support vector machines and generalized linear models. With Core ML 2, developers can run on-device machine learning models without the need to analyze data across multiple servers.

The Core ML 2 Vision Framework has also improved in iOS 12. Developers can build vision machine learning frameworks directly into mobile apps. The framework now supports improved face tracking, face, landmark, text, barcode and object detection, as well as, enhanced image registration for AR apps.

Additionally, Create ML comes to iOS 12 this year. This new framework lets developers easily build machine learning models, with little to no machine learning expertise. This new addition Apple’s machine learning suite is familiar and comfortable to use thanks to it’s similarities to Swift. As well, Create ML is integrated into Xcode 10 playgrounds making it easy to view model workflows in real time.

Only a few lines of Swift code are necessary to leverage the vision and natural language technologies available on iOS 12 and create in-depth models optimized for the Apple ecosystem. Developers can use Create ML to accomplish some tasks included regression, image classification, word tagging, and sentence classification. As a bonus, developers don’t need a separate server; macOS can train custom data.

Learn More: 8 Advantages of Using Swift for iOS Development

Cutting Through the iOS 12 Notification Hype

There’s been a lot of buzz recently about how iOS 12 will treat push notifications. iOS 12 gives users a considerable amount of control over what push notifications they receive and how they receive them. Specifically:

• Users have access to message settings directly from the push notification interface allowing them to opt-out of messages from the device’s lockscreen.
• iOS 12 has enhanced downtime settings which will enable users to ignore push notifications entirely.
• As mentioned above, Siri is infinitely more active in predicting, handling, and sending personalized push notifications based on usage data and in-app behaviour insights.
• Users have the option to group push notifications by theme or by mobile app and swipe away several notifications at once without seeing all of the content.

Source

These changes are causing quite the commotion among mobile app marketers who have been forced to pivot to keep getting value from push campaigns. Now that users have access to revealing insights about their digital time spend, users are demanding better content from mobile apps and high-value push notifications that justify their attention. While iOS 12 may put some hurdles between you and your users, they are also giving you the resources you need to create quality push notifications that are valuable, personable, and relevant.  

Notification content app extensions now support interactivity in iOS 12. If you’re delivering push notification content to encourage user action, you can now add buttons and switches to your push notifications. Here’s how it works – when an iOS device receives a notification, the content comes in two parts: the first interface display is an abbreviated banner including the message title, subtitle, and two to four lines of body text; the second interface display activates when a user presses the abbreviated banner. When the user presses the content, the device will display the full notification interface, including any notification-related actions.

On top of interactivity support, iOS 12 now allows developers to customize the full notification interface. The ability to customize notifications is only supported in native iOS app development and gives developers the ability to:

• Customize the arrangement of interface times, including the push notification’s title, subtitle, and body text.
• Replace fonts or substitute styling for interface elements.  
• Include custom imaging or branding materials.

iOS 12 delivers an entirely new model of push notification delivery – a model that calls for undeniably useful content. The challenge is there, but iOS 12 has also given mobile app marketers plenty of opportunities to deliver relevant, attention-grabbing value in push campaigns.

A Brief Note on Apple CarPlay

The iOS 12 CarPlay updates add a small side note for app developers to keep on their radar: CarPlay now supports third-party navigation apps. iOS 12 has introduced a system-generated, system-hosted and customizable interface to display navigations apps. This new framework continues to govern CarPlay’s UI elements but allows developers to display custom app content.

No Password? No Problem.

At WWDC back in June, Apple announced they would be simplifying the existing login and account creation process for iOS apps. Now with iOS 12, developers have access to Password Autofill. This new and convenient feature is something developers should consider working into their existing apps or including in new products. With only a few taps, users can create and save new passwords and log in to existing accounts. What’s more amazing is users don’t even need to know their password; the system handles everything. How? By default, Password Autofill saves a user’s password on the device, which they can share across devices using the iCloud keychain.

Not only does this enhancement increase app security because Autofill suggests strong, unique passwords from the start, but it also dramatically enhances the onboarding process. A key to mobile app onboarding is to build the path of least resistance. Complicated registration fields can harm user acquisition efforts and increase user abandonment, but with Password Autofill, users can begin using new apps quicker and access content across devices without complication.

Choosing the Right Features For Your iOS 12 App

These are the top developer-focused features included in the iOS 12 release; however, many of these new features work to benefit the end-user. It should be an exciting year for iOS apps as the new functionality starts to become featured in the App Store.

Choosing the right features for your mobile app project is an essential part of the entire development process. It’s necessary for your team to determine the product’s purpose, requirements, and functionality to guide the strategic direction of the project.

Do you need help planning your mobile app requirements? Our free, customizable Product Requirements and Planning Template can help. Or, read more about How to Build a Mobile App Requirements Document.