There are many advantages to this approach. This allows our teams to work more effectively concurrently, to deliver & deploy enhancements more quickly, and to provide a wide-range of flexible options to our customers.

Our iOS and Android industry solutions are made up of modules, which sit on top of SDKs, which call various APIs. Let’s look into each of these in more detail.

Industry Solutions

Phunware provides tailored industry solutions for healthcare, hospitality, and various other sectors, offering personalized mobile apps designed to enhance customer satisfaction. From the moment they leave home to every step of their visit and back again, consumers expect a seamless experience.

Some of our largest customers, like Atlantis Bahamas, Gaylord Hotels, and Virginia Hospital Center, appreciate the rapid deployment and easy updates our solutions provide.

Our mobile app solutions are packed with features like dynamic content, indoor wayfinding, push notifications, analytics, and more—all designed to enhance user experiences.

Under the hood, these solutions are pre-integrated with several of our modules, described below.

Modules

You can think of modules as different components of a mobile app that have a specific feature set.

For example, our Mapping Module includes everything an app might need to deliver a robust wayfinding experience. The app simply needs to launch the Mapping Module and the user is now presented with a map displaying points of interest, search capabilities, and a discovery section.

Features such as static routing, GPS routing, and indoor BLE routing are supported. Users can select handicap accessible routing, enable voice directions, view turn-by-turn directions, or tap on points of interest to view detail pages.

Another popular module is our Mobile Engagement Module, which includes support for broadcast push notifications, geofence alerts, and beacon proximity messaging, all with a nice inbox to hold those messages and allow users to view promotions or re-trigger links.

Other modules include the Core Module, which handles content management, Forms Module, for form input, and Permissions Module, for handling app permissions such as location, bluetooth, or push notifications.

SDKs

But what if a customer wants the capabilities we offer, but prefers to develop their own UI and UX? That’s where SDKs come in. Our native iOS and Android SDKs act as true Software Development Kits. Third party developers can integrate our Mapping & Location SDK, Analytics SDK, or Mobile Engagement SDK and create whatever UI/UX they can imagine. We provide sample code, but it’s up to the developers to decide the look and feel.

APIs

Just about every app will need to connect to a web service to perform actions such as downloading content, registering for push notifications, or sending analytics.

Our solutions are no different. They are powered by our RESTful APIs for Mapping, Location, Content Management, Mobile Engagement, and Analytics.

The same is true for our web portal. When a customer updates their map, changes a piece of content, sets up a push notification campaign, or views how many app launches they received, they are using the same APIs that our SDKs use to deliver those experiences to end users.

Advantages

Now that we’ve covered our modular approach to architecture, it’s time to discuss the advantages.

The first is that this approach allows our developers to work on different components of our solutions without stepping on each other’s toes. For example, each module is in its own code repository so the developer working on the Mapping Module isn’t going to create merge conflicts for the developer working on the Mobile Engagement Module. It also allows developers to become specialists focusing on specific feature sets.

The second advantage is that this approach allows us to roll out changes quickly. For example, let’s say we wanted to add a new feature to our map. It wouldn’t make sense to make this change in every app codebase. Instead we implement it in the Mapping Module and release a new version. Each app, whether it’s a Phunware-developed Industry Solution app or a third-party developed custom app, can simply update to the latest version of the Mapping Module to receive the changes. This is as simple as updating the version number in a dependency management configuration file and rebuilding.

Finally, another major advantage to this approach is that we are able to offer a wide range of options for our customers. For the customers who want a complete solution, our Industry Solutions contain everything pre-integrated and ready to submit to the store. For customers who have an existing app, a better option might be to license individual modules. For example, a customer can add wayfinding capabilities to their app with a drop-in Mapping Module that can be integrated in as little as a day. For the customer who just wants the wayfinding capabilities but would prefer to design their own UI and UX, the Mapping & Location SDK is ideal for that. And for those who want maximum control, our APIs are always available.

At Phunware, we see ourselves as more than just a technology provider—we’re your partner in success. Think of us as your concierge in unifying your customers’ journey. Whether you need the complete solution or just the key components to build it yourself, we’re here to support you every step of the way. From design and implementation to integration, launch, adoption, and ongoing support, we ensure a seamless experience that lasts for years to come

As always, feel free to reach out! Contact us and our team of experts will guide you through Phunware’s mobile solution offerings, showing you how they can be tailored to meet your unique needs.

The post Tech Blog: Modular Approach to Mobile App Architecture appeared first on Phunware.

When defining a new feature for a mobile app, it’s important to follow best practices to ensure the feature is complete, stable, and easy to maintain.

Let’s use a new Leaderboard screen as an example. A less experienced manager may write user stories for the Engineering team asking them to satisfy acceptance criteria that ensures the proper UX is followed, the UI matches the designs, and the points are populated by the appropriate data source. But there is so much more to consider.

Feature Flags

It’s imperative that a mobile app has an external config file. This file will typically contain various configuration settings, urls, strings, etc that an app needs before it launches. Phunware’s Content Management Engine is a great place for developers to create a JSON-based app config file. 

Feature flags are an important component of any config file. Feature flags are simply set to true or false and determine whether a feature should be enabled or not. Using our Leaderboard screen example, we may not want to launch the Leaderboard feature until the first of the month. We can go live with the app release, but keep the flag set to false until we’re ready for users to experience it in production. 

This is also helpful if an issue occurs and the data populating the Leaderboard is corrupt. Rather than delivering a poor user experience, we can temporarily disable the Leaderboard until the issue is resolved.

Externalized Strings & Images

The app config file is also a great place to externalize text strings and image URLs.

Let’s say there’s a typo in our Leaderboard screen or a Product Manager simply wants to change the copy. It’s much quicker and easier to update the text in the config file than to make the changes in code, submit to the stores, wait for approval, and then try to get all our users on the latest app version.

At Phunware, we actually take this a step further and externalize strings for each language. For example, we may have a strings_en key for English strings and a strings_es key for Spanish strings. We serve the appropriate text depending on the user’s language settings.

Externalizing image URLs is also helpful when we want to change images on-the-fly. We’re always uploading new images to Phunware’s Asset Manager and updating URLs.

Analytics
After launching a great feature, we’re going to want to know how it performs. Are users visiting the Leaderboard screen? Are they interacting with the filters?

Analytics is often an afterthought. If we train ourselves to write a corresponding analytics ticket whenever we write a feature ticket, we’ll find that our coverage will be very complete.

Phunware Analytics is a great tool for capturing app launches, unique users, retention cohorts, screen views, and custom event analytics.

Error Handling

So we wrote user story tickets for the Leaderboard screen and the developers have finished implementing it. But what happens when the API goes down and returns a 500 error? Will the app provide an informative error message, a generic one, or simply get into a bad state?

By writing an error handling ticket we can define the behavior we would like when something goes wrong. At Phunware, we like to use a mix of specific and generic error messages.

For the Leaderboard example it may be more appropriate to display a message such as “Unable to load Leaderboard data. Please try again later” rather than “An unexpected error has occurred”. However, the latter might be best as a catch all for any situation where a specific error message wasn’t implemented.

Deep Links

Chances are, if the new Leaderboard is doing well, someone is going to ask if they can send a push notification promoting the Leaderboard which, when tapped, sends users to the Leaderboard screen.

If we considered deep links when writing the initial user stories then we’re probably covered. These days there are many places that may link into an app. Deep links can come from push notifications, app share URLs, emails, or even websites redirecting to the mobile app.

Considering deep links when implementing a new screen saves the time and overhead of having to do the work in a follow up release.

Offline Caching

There are times that our users have a poor network connection. Perhaps they are on a train or their WiFi is down. Ideally we realized that this may occur and tried to create a good user experience when it does.

At Phunware, we make sure to cache as much content as possible. If the user launches the app without an internet connection we’ll still display the images and content that were available the last time they launched the app.

While it’s possible some of the content is outdated, this is a better experience than showing a blank screen.

Displaying a banner at the top showing the user doesn’t appear to have a connection is also helpful in informing the user they are being shown something slightly different than if they had a good connection.

Unit Tests

We try to cover as much of our code as possible with Unit Tests and write them when developing new features.
Unit Tests allow developers to be confident the feature works as expected. We set up our build jobs to run unit tests when new builds are being generated, so a few months down the road, if a developer introduces a regression, we catch it right away. This frees up our QA team to focus on edge case issues rather than discovering breaking changes.

Documentation

So we wrote the user stories the Engineering team needed to implement the Leaderboard screen. Everything has been externalized, deep links have been tested, analytics are in place, and unit tests are all passing. Now it’s time to update the documentation.

Keeping documentation up to date is very important as codebases and feature sets are always changing. Ensuring we have proper documentation allows team members to quickly look up that deep link URL scheme or the analytics event that fires when a user toggles something in the Leaderboard.

In addition to documentation, this is also a great time to update submission checklists and QA test plans, since we’ll want to make sure the new Leaderboard is tested with each new release.

Store Guidelines

Our final best practice to follow is keeping up to date with Google and Apple’s App Store Review Guidelines. We check these weekly because we never know when new guidelines will be announced.

It’s critical to know these before the feature is completed and the app is submitted. There’s nothing worse than getting rejected because we violated a guideline. At that point any deadline we had to launch the app went out the window.

For example, there’s a guideline that requires that any app that allows users to create accounts must also provide a mechanism for users to delete their account. If we knew this when writing that user story for Sign Up and Log In, then we’re covered. If we found out the hard way, then we’ve lost precious time because it may be another sprint or two before the Engineering team can deliver that new flow.

Luckily we followed the other best practices and we’re able to disable it for now!

The post Tech Blog: Engineering Best Practices appeared first on Phunware.

When it launches this fall, iOS 14 will bring several new permission changes for requesting access to the user’s location, advertising id, photos, and local network. This blog breaks down the upcoming changes and provides recommendations on how best to handle these new privacy-related permission prompts.

Location Permission Changes

Apple is continuing with its commitment to give app users more control over their data and privacy. Last year, with the release of iOS 13, Apple gave users the option to decide if the app should have access to their location only once, only while using the app, or always. 

This year, with the release of iOS 14, Apple will build upon that and allow users also to decide if the app should have access to their precise location or just their approximate location.

New: Precise Location Toggle

When an app requests the user’s location, the user will be presented with a permission prompt asking for location access with the same options as iOS 13: Allow Once, Allow While Using App, or Don’t Allow. 

Like with previous versions of iOS, the title of the permission prompt is controlled by Apple, but the app developer configures the subtext. The subtext is intended to provide the user with an explanation of why the app is requesting this permission. 

What’s new in iOS 14 is the user’s ability to toggle precise location on and off. The precise setting is enabled by default, which means the app will get the user’s fine location. If the user disables this, then the app will only get the user’s approximate location. In our tests, the approximate location may return location coordinates for a user up to 2 miles away. 

New: Temporary Request for Precise Location

Another change is the app’s ability to temporarily request precise location if the user previously only allowed approximate accuracy. This is a one-time permission request that, if granted, only lasts during the duration of the app session. According to Apple, “This approach to expiration allows apps to provide experiences that require full accuracy, such as fitness and navigation apps, even if the user doesn’t grant persistent access for full accuracy.”

Background Location Permission

App developers may need the user’s location in the background to support features such as Geofence notifications. Same as in iOS 13, Apple doesn’t allow this option on the first request but instead allows the app developer to request this permission at a later time. If your app requested Always Allow permission, then this prompt will be displayed automatically the next time the user launches the app, but typically not the same day the initial prompt was displayed.

Once an app has received the user’s location in the background a significant number of times, Apple will inform the user and ask them if they want to continue allowing this. This is also unchanged from iOS 13. 

New: Updated Location Settings

Users can adjust their location settings in the iOS Settings app by navigating to Privacy → Location Services → App Name.

Users will have the option to adjust their location access to Never, Ask Next Time, While Using the App, or Always.

If a user receives a location permission prompt and selects Allow Once, their location setting will be Ask Next Time, prompting them to make a selection again the next time the app requests their location.

What’s new in iOS 14 is the Precise Location toggle, which allows users to switch between precise and approximate location.

Impact

The most significant impact of these changes will be on apps that require a precise location, such as navigation apps or apps that use geofence notifications. Given that an approximate location could put the user miles away, the precise location option is required for these apps. 

As mentioned earlier, the app has the option to temporarily request precise location from a user who has previously only granted approximate location. This request can be triggered when the user begins a task that requires fine location, such as wayfinding. 

However, there isn’t an explicit user action to trigger this temporary permission request when it comes to geofence notifications, so the temporary precise location prompt won’t help us here.  

In addition, geofence notifications require the Always Allow background location selection, so apps that promote this feature will feel the impact most.

Recommendations

• Don’t request the user’s location until you need it.
• Include a usage description clearly explaining why you need the user’s location.
• Don’t request Always Allow permission unless you have a feature that requires the user’s location when the app is closed or backgrounded.
• If you require precise location, but the user has only granted approximate location, use a one-time temporary precise location request.
• If you require Always Allow + Precise location settings for Geofences, but the user hasn’t granted this, then to increase user acceptance, include a custom alert or screen informing the user the benefit of allowing this and provide instructions on how they can change this in iOS Settings, with a button that deep links them there. 
• Remember, if the user chooses Don’t Allow, you won’t be able to request this permission again.

IDFA Permission Changes

The IDFA, or Identifier for Advertisers, is going to change as we know it. Ad agencies have relied on this device identifier for years to track users across apps and websites to learn their habits and interests so that they can target them with relevant ads. 

This was made more difficult with the release of iOS 10 when users could enable a Limit Ad Tracking setting, which would return all zeroes for this identifier. Before that, the only thing a user could do is reset their identifier value, but this was seldom used.

New: IDFA Prompt

iOS 14 brings the strongest changes to the IDFA yet, which may effectively kill it as the primary way advertisers track users. Rather than defaulting to having the IDFA available, developers will now have to prompt the user to allow access to the IDFA. 

The wording in the permission prompt will undoubtedly lead to a majority of users declining this permission: “App would like permission to track you across apps and websites owned by other companies.“

Like the Location Permission prompt, the IDFA prompt’s title is controlled by Apple, but the app developer configures the subtext. Developers will have to come up with a usage description convincing enough to persuade users to allow themselves to be tracked.

According to Apple, “The App Tracking Transparency framework is only available in the iOS 14 SDK. This means that if you haven’t built your app against iOS 14, the IDFA will not be available and the API will return all zeros.”

However, on September 3, 2020, Apple extended the deadline to 2021, by stating, “To give developers time to make necessary changes, apps will be required to obtain permission to track users starting early next year.“

New: Updated IDFA Settings

Also new in iOS 14 is a toggle in iOS Settings that, when disabled, prevents app developers from ever prompting the user for permission to use their IDFA. A user can find this in the iOS Settings app under Privacy → Tracking and applies globally to all apps. 

Impact

The most significant impact will be on the ad industry. Without a guaranteed way of tracking users across apps and websites, advertisers will need to rely on less tracking users’ ways of tracking. Since getting the user’s IDFA was never guaranteed, advertisers already have fallbacks methods for tracking users. Such methods include fingerprinting, where a collection of other information about the user, such as IP address, device model, and rough location, is used to verify that they are the same user. Another option is to use sampling since there will still be some users who allow themselves to be tracked. For example, if 5% of tracked users installed the app through a particular install ad, one can presume that about 5% of all users can be attributed to that campaign. 

Recommendations

• Don’t request the user’s IDFA if your use case can be satisfied with the IDFV (Identifier for Vendor) instead. The IDFV is similar to the IDFA in the sense that it’s a unique identifier for the user. However, each app developer will be assigned a different IDFV per user, so this doesn’t help in tracking users across apps and websites by other developers. Since there are no privacy concerns, there is no permission prompt needed to obtain the IDFV and the user has no way to disable this.
• Include a usage description clearly explaining why you’d like to track the user across apps and websites
• Consider a custom prompt in advance of the official IDFA permission prompt to provide your users with more context before the scary system prompt is presented.
• If a user declines the IDFA permission and you need to track them outside your app, use probabilistic methods such as fingerprinting or sampling.
• Remember that if the user chooses Ask App Not to Track or if they disable the ability to prompt for this permission in Settings, then you won’t be able to request this permission. The best you can do at that point is to detect that they declined this permission, show some custom prompt, and direct them to the Settings app to enable the permission there.

Photo Permission Changes

Apple has required users to grant permission to their cameras or photos since iOS 8. However, this was an all-or-nothing permission, giving the developer access to all Photos. New in iOS 14 is the ability for users to choose if they want to grant access to all photos or only specific photos. 

New: Select Specific Photos

The initial photo permission prompt will ask the user if they would like to grant access to one or more specific photos, grant access to all photos, or decline this permission. A user who is simply trying to upload one specific photo may choose only to grant access to that photo. 

If a user only grants access to specific photos, the next time the app requests the photo permission, the user will receive a slightly different permission prompt. The new prompt will ask them if they would like to allow access to more photos or keep the current selection of photos they’ve previously allowed. 

New: Updated Photo Settings

Users can adjust their location settings in the iOS Settings app by navigating to Privacy → Photos  → App Name. Users can choose from the following options: Selected Photos, All Photos, or None. 

If Selected Photos is chosen, then an option to Edit Selected Photos appears. Tapping this presents a Photo Picker, which includes search functionality, the ability to view albums, and the ability to view previously selected photos. 

Note: The permission prompts and settings options only refer to photos. However, the same applies to videos.

Impact

This new privacy change should have minimal impact on apps that require the user to grant permission in order to upload specific photos or videos. The biggest impact will be on apps requiring permission to the entire camera roll, such as Google Photos. 

Recommendations

• Don’t request photo access until the user is performing an action that requires this, such as uploading a photo or video.
• Include a usage description clearly explaining why your app requires this permission.
• Remember that these permission changes apply to videos as well.
• Remember that if the user chooses Don’t Allow, you won’t request this permission again. The best you can do at that point is to detect that they declined this permission, show some custom prompt, and direct them to the Settings app to enable the permission there. 

Local Network Permission Changes

There are many legitimate reasons an app might need to use the local network. For example, it may connect to a printer, search for nearby players for a game, or control the lights in a home. 

At the same time, there are also less legitimate reasons that apps use the local network. They could be collecting information about the devices on the local network to create a “fingerprint,” which allows them to infer that a user is at home, even if without granting location permission.

In iOS 13, Apple required apps to request permission for access to Bluetooth. Now in iOS 14, they are doing the same for the local network. If your app communicates to devices over your home WiFi, for example, then it is operating over the local network and will trigger this new permission prompt. 

There are exceptions to system-provided services such as AirPrint, AirPlay, AirDrop, or HomeKit. These system services handle device discovery without exposing the full list of devices to the app, so they are exempt from triggering this permission prompt. 

Any other network connections outside the local network (e.g., Web Services, APIs, or other connections to the internet) are not impacted and do not require permission.

New: Local Network Prompt

When an app tries to connect to the local network, it will trigger a Local Network Permission Prompt even if only to view available devices.

Impact

Many applications use the local network for use cases other than the system services previously mentioned. We’ve found that most streaming apps trigger this permission prompt upon launch, likely because they support Google Cast. There may be apps that have Analytics SDKs that collect this type of information. Those apps will also display this prompt upon app launch. 

Recommendations

• Add logic to defer this permission prompt until the user performs an action that requires it, such as searching for nearby players or casting a video.
• Include a usage description clearly explaining why your app needs to use the local network.
• Remember that if you change nothing before iOS 14 release date and your app uses the local network, this permission prompt will be one of the first things the users see when they launch your app on iOS 14. 
• Remember that if the user chooses Don’t Allow, you won’t request this permission again. The best you can do at that point is to detect that they declined this permission, show some custom prompt, and direct them to the Settings app to enable the permission there. 

Other Privacy Changes

New: Microphone/Camera Indicator

iOS 14 will display a colored dot in the status bar, indicating the current app is actively using the microphone or camera. Be careful not to use any low-level camera/microphone APIs unless the user is performing an action to capture audio or video. 

New: Pasteboard Alerts

iOS 14 will display a banner at the top of the screen, indicating the current app has just extracted the contents of the user’s Pasteboard (also known as clipboard). Some apps use the pasteboard to detect copied URLs to surface the right information when the user moves to their native app. 

Be careful with any Analytics SDKs you include in your app that may be collecting this user data.

More Info

For a quick and easy reference to the iOS 14 permission changes discussed in this blog, download our Location Cheat Sheet:
Download The Location Cheat Sheet

WWDC 2020 Videos

• Build trust through better privacy
• Design for location privacy
• Support local network privacy in your app

At Phunware, our Engineering team is dedicated to staying up-to-date with the latest changes from Apple WWDC and Google I/O. If you’re a Product Manager looking for a Location or Analytics SDK built by a team that understands these privacy-related changes, then visit our Products page for a complete list of our software products, solutions, and services.

The post Navigating Permission Changes in iOS 14 appeared first on Phunware.