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.

There are many ways to build a code scanner on iOS. Apple’s Vision Framework introduced additional options. We will first go over the classic tried and true method for creating a code scanner, then we will go over the new options. We will carefully consider the pros and cons for each approach.

1. The Classic Approach

Throughout the years most scanners on iOS have likely taken the following approach.

source: Apple WWDC ’22

First AVFoundation is used to set up a video capture session, highlighted in gray in the diagram above. Then an AVCaptureMetaDataOutput object is hooked up to the video session’s output. AVCaptureMetaDataOutput is then set up to emit barcode information which is extracted from an AVMetadataObject (highlighted in blue).

Pros:

• When it comes to scannable code formats, there aren’t any formats that are exclusive to the newer approaches. Click here to see a full list of supported code formats.
• Minimum deployment target is iOS 6. This approach will likely accommodate any OS requirements that you may have.
• This approach is tried and true. This means there are plenty of code examples and stack overflow questions.

Cons:

• The maximum number of codes that can be scanned at a time is limited. For 1d codes we are limited to one detection at a time. For 2d codes we are limited to four detections at a time. Click here to read more.
• Unable to scan a mixture of code types. For example a barcode and a QR code can’t be scanned in one go, instead we must scan them individually.
• The lack of machine learning may cause issues when dealing with problems like a lack of focus or glare on images.
• Developers have reported issues when supporting a variety of code types on iOS 16. A solution could be to use one of the newer approaches for your users on iOS 16 and above.

2. AVFoundation and Vision

For the following approach the basic idea is to feed an image to the Vision Framework. The image is generated using an AVFoundation capture session, similar to the first approach. Click here for an example implementation.

source: Apple WWDC ’22

Notice the three Vision Framework classes in the diagram above (in blue). The entry point to the Vision Framework is the VNImageRequestHandler class. We initialize an instance of VNImageRequestHandler using an instance of CMSampleBufferRef.

Note: VNImageRequestHandler ultimately requires an image for Vision to process. When initialized with CMSampleBufferRef the image contained within the CMSampleBufferRef is utilized. In fact there are other initialization options like CGImage, Data, and even URL. See the full list of initializers here.

VNImageRequestHandler performs a Vision request using an instance of VNDetectBarcodesRequest. VNDetectBarcodesRequest is a class that represents our barcode request and returns an array of VNBarcodeObservation objects through a closure.

We get important information from VNBarcodeObservation, for example:

• The barcode payload which is ultimately the data we are looking for.
• The symbology which helps us differentiate observations/results when scanning for various types of codes (barcode, QR, etc) simultaneously.
• The confidence score which helps us determine the accuracy of the observation/result.

In summary, it took three steps to setup Vision:

1. Initialize an instance of VNImageRequestHandler.
2. Use VNImageRequestHandler to perform a Vision request using an instance of VNDetectBarcodeRequest.
3. Set up VNDetectBarcodeRequest to return our results, an array of VNBarcodeObservation objects.

Pros:

• Computer Vision and Machine Learning algorithms – The Vision Framework is constantly improving. In fact, at the time of writing Apple is on its third revision of the barcode detection algorithm.
• Customization – Since we are manually hooking things up we are able to customize the UI and the Vision Framework components.
• Ability to scan a mixture of code formats at once. This means we can scan multiple codes with different symbologies all at once.

Cons:

• Minimum deployment target of iOS 11, keep in mind that using the latest Vision Framework features will increase the minimum deployment target.
• Working with new technology can have its downsides. It may be hard to find tutorials, stack overflow questions, and best practices.

3. DataScannerViewController

If the second approach seemed a bit too complicated, no need to worry. Apple introduced DataScannerViewController which abstracts the core of the work we did in the second approach. Although it’s not exclusive to scannable codes, it can also scan text. This is similar to what Apple did with UIImagePickerViewController, in the sense that it’s a drop in view controller class that abstracts various common processes into a single UIViewController class. Apple provides a short article that introduces the new DataScannerViewController class and walks through the required setup and configuration.

Pros:

• Easy to use and setup.
• Low maintenance, Apple is in charge of maintaining the code.
• Can also scan text, not exclusive to machine readable codes.

Cons:

• Minimum deployment target of iOS 16.
• Only available on devices with the A12 Bionic chip and later.
• Limited control over the UI, even if the UI looks great sometimes we may require something more complex.

Conclusion

We went over the various ways to scan machine readable codes on iOS. We explored the pros and cons of each approach. Now you should be ready to use this knowledge to build or improve on a barcode scanner.

Who knows, you may even choose to take a hybrid approach in order to take advantage of the latest and greatest that Apple has to offer while gracefully downgrading for users on older iOS devices.

The post Dev Blog: Barcode Scanning on iOS appeared first on Phunware.

A regular expression (regex) is a sequence of characters that defines a search pattern which can be used for string processing tasks such as find/replace and input validation. Working with regular expressions in the past using NSRegularExpression has always been challenging and error-prone. Swift 5.7 introduces a new set of APIs allowing developers to write regular expressions that are more robust and easy to understand.

Regex Literals

Regex literals are useful when the regex pattern is static. The Swift compiler can check for any regex pattern syntax errors at compile time. To create a regular expression using regex literal, simply wrap your regex pattern by the slash delimiters /…/

let regex = /My flight is departing from (.+?) \((\w{3}?)\)/

Notice the above regex literal also has captures defined in the regex pattern using the parentheses (…). A capture allows information to be extracted from a match for further processing. After the regex is created, we then call wholeMatch(of:) on the input string to see if there’s a match against the regex. A match from each capture will be appended to the regex output (as tuples) and can be accessed by element index. .0 would return the whole matched string, and .1 and .2 would return matches from the first and second captures, respectively.

let input = "My flight is departing from Los Angeles International Airport (LAX)"

if let match = input.wholeMatch(of: regex) {
    print("Match: \(match.0)")
    print("Airport Name: \(match.1)")
    print("Airport Code: \(match.2)")
}
// Match: My flight is departing from Los Angeles International Airport (LAX)
// Airport Name: Los Angeles International Airport
// Airport Code: LAX

You can also assign a name to each capture by prefixing ?<capture_name> to the regex pattern, that way you can easily reference the intended match result like the example below:

let regex = /My flight is departing from (?<name>.+?) \((?<code>\w{3}?)\)/

if let match = input.wholeMatch(of: regex) {
    print("Airport Name: \(match.name)")
    print("Airport Code: \(match.code)")
}
// Airport Name: Los Angeles International Airport
// Airport Code: LAX

Regex

Along with regex literals, a Regex type can be used to create a regular expression if the regex pattern is dynamically constructed. Search fields in editors is a good example where dynamic regex patterns may be needed. Keep in mind that Regex type will throw a runtime exception if the regex pattern is invalid. You can create a Regex type by passing the regex pattern as a String. Note that an extended string literal #”…”# is used here so that escaping backslashes within the regex is not required.

Regex Builder

Another great tool for creating regular expressions is called regex builder. Regex builder allows developers to use domain-specific language (DSL) to create and compose regular expressions that are well structured. As a result, regex patterns become very easy to read and maintain. If you are already familiar with SwiftUI code, using regex builder will be straightforward.

The following input data represents flight schedules which consists of 4 different fields: Flight date, departure airport code, arrival airport code, and flight status.

let input =
""" 
9/6/2022   LAX   JFK   On Time
9/6/2022   YYZ   SNA   Delayed
9/7/2022   LAX   SFO   Scheduled
"""

let fieldSeparator = OneOrMore(.whitespace)


let regex = Regex { 
    Capture {
        One(.date(.numeric, locale: Locale(identifier: "en-US"), timeZone: .gmt)) 
    } 
    fieldSeparator
    Capture { 
        OneOrMore(.word) 
    } 
    fieldSeparator
    Capture { 
        OneOrMore(.word)
    }
    fieldSeparator
    Capture { 
        ChoiceOf {
            "On Time"
            "Delayed"
            "Scheduled"
        }
    }
}

Quantifiers like One and OneOrMore are regex builder components allowing us to specify the number of occurrences needed for a match. Other quantifiers are also available such as Optionally, ZeroOrMore, and Repeat.

To parse the flight date, we could have specified the regex pattern using a regex literal /\d{2}/\d{2}/\d{4}/ for parsing the date string manually. In fact, there’s a better way for this. Luckily, regex builder supports many existing parsers such as DateFormatter, NumberFormatter and more provided by the Foundation framework for developers to reuse. Therefore, we can simply use a DateFormatter for parsing the flight date.

Each field in the input data is separated by 3 whitespace characters. Here we can declare a reusable pattern and assign it to a fieldSeparator variable. Then, the variable can be inserted to the regex builder whenever a field separator is needed.

Parsing the departure/arrival airport code is straightforward. We can use the OneOrMore quantifier and word as the type of character class since these airport codes consist of 3 letters.

Finally, ChoiceOf lets us define a fixed set of possible values for parsing the flight status field.

Once we have a complete regex pattern constructed using regex builder, calling matches(of:) on the input string would return enumerated match results:

for match in input.matches(of: regex) {
    print("Flight Date: \(match.1)")
    print("Origin: \(match.2)")
    print("Destination: \(match.3)")
    print("Status: \(match.4)")
    print("========================================")
}
// Flight Date: 2022-09-06 00:00:00 +0000
// Origin: LAX
// Destination: JFK
// Status: On Time 
// ======================================== 
// Flight Date: 2022-09-06 00:00:00 +0000 
// Origin: YYZ 
// Destination: SNA 
// Status: Delayed 
// ======================================== 
// Flight Date: 2022-09-07 00:00:00 +0000 
// Origin: LAX 
// Destination: SFO 
// Status: Scheduled 
// ========================================

Captures can also take an optional transform closure which would allow captured data to be transformed to a custom data structure. We can use the transform closure to convert the captured value (as Substring) from the flight status field into a custom FlightStatus enum making it easier to perform operations like filtering with the transformed type.

enum FlightStatus: String {
    case onTime = "On Time"
    case delayed = "Delayed"
    case scheduled = "Scheduled"
}

let regex = Regex { 
    ...
    Capture { 
        ChoiceOf {
            "On Time"
            "Delayed"
            "Scheduled"
        }
    } transform: {
        FlightStatus(rawValue: String($0))
    }
}
// Status: FlightStatus.onTime

Final Thoughts

Developers who want to use these new Swift Regex APIs may question which API they should adopt when converting existing code using NSRegularExpression or when writing new code that requires regular expressions? The answer is, it really depends on your requirements. Each of the Swift Regex APIs has its own unique advantage. Regex literals are good for simple and static regex patterns that can be validated at compile time. Regex type is better suited for regex patterns that are constructed dynamically during runtime. When working with a large input data set requiring more complex regex patterns, regex builder lets developers build regular expressions that are well structured, easy to understand and maintain.

Learn More

• WWDC 2022: Meet Swift Regex
• WWDC 2022: Swift Regex: Beyond the basics
• Apple Developer Documentation: RegexBuilder

The post Dev Blog: Swift Regex appeared first on Phunware.

Android 13 introduces a new runtime permission, android.permission.POST_NOTIFICATIONS, which apps will need to obtain to display some types of notifications. How does this change the ability of apps to post notifications? I’ll attempt to answer that and more in this post. My own research found answers that surprised me.

Why does an app need POST_NOTIFICATIONS permission?

Figure 1: Android 13 system dialog for notifications permission.

The POST_NOTIFICATIONS permission only exists on Android 13 (the permission value “android.permission.POST_NOTIFICATIONS” is only available in code when an app compiles to API 33). When the app is running on devices with Android 12 and lower, POST_NOTIFICATIONS permission is not needed (and, actually, should not be used, more on this later). On Android 13, some notifications can still be displayed without this permission, such as notifications for foreground services or media sessions as described in the documentation. On Android 13, you can think of this permission as having the same value as the app system setting to enable notifications but you can ask the user to enable notifications like a permission without sending them to the system settings screen.

How can my app check if it has POST_NOTIFICATIONS permission?

As a runtime permission, you would think the obvious way to check for this permission is to call checkSelfPermission with the POST_NOTIFICATIONS permission. But this does not work as expected on pre-Android 13 devices. On pre-Android 13 devices, checkSelfPermission(POST_NOTIFICATIONS) will always return that the permission is denied even when notifications have been enabled in the app system settings. So, don’t call checkSelfPermission(POST_NOTIFICATIONS) if the app is not running on Android 13. Calling areNotificationsEnabled() is still the way to check that the user has enabled notifications for your app. To put it another way, only on Android 13 will checkSelfPermission(POST_NOTIFICATIONS) and areNotificationsEnabled() give you the same answer of whether that app has notifications enabled or not.

How can my app get POST_NOTIFICATIONS permission?

First, even apps that do not ask for POST_NOTIFICATIONS permission (such as apps that have not yet been updated to API 33 to know about this permission) may still obtain it. If an app is already installed, and has notifications enabled, and the device updates to Android 13, the app will be granted the permission to continue to send notifications to users. Similarly, if a user gets a new device with Android 13 and restores apps using the backup and restore feature, those apps will be granted POST_NOTIFICATIONS permission, if notifications were enabled.

For newly installed apps, if an app targets API 32 or lower, the system shows the permission dialog (see Figure 1) the first time your app starts an activity and creates its first notification channel. This is why you will see the permission dialog for apps that have not yet been updated for Android 13.

But as a developer, I was looking to add requesting the POST_NOTIFICATIONS permission to apps. Here’s the code I used:

    private val requestPermissionLauncher =
        registerForActivityResult(
            ActivityResultContracts.RequestPermission()
        ) { isGranted: Boolean ->
            onNotificationPermission(isGranted)
        }
…
        requestPermissionLauncher.launch(POST_NOTIFICATIONS)

Like checkSelfPermission(), this did not work the way I expected. On pre-Android 13 devices, requesting the POST_NOTIFICATIONS permission will always return PERMISSION_DENIED without displaying the system dialog. Also, if the app targets API 32 or lower, requesting the POST_NOTIFICATIONS permission will always return PERMISSION_DENIED without displaying the system dialog, even on devices with Android 13. So to request, the POST_NOTIFICATIONS permission at runtime:

• Only request it on Android 13 or later
• Your app must target API 33 or later

Do I need to update my app?

Yes, you should update your app if you don’t want the app to lose the ability to display notifications. Because of the situations described above where an app can get the POST_NOTIFICATIONS permission even when no code asks for it, you may be tempted to procrastinate just a little longer before handling this new permission. But remember the auto-reset permissions for unused apps feature introduced with Android 11 and later rolled out to earlier versions. This feature applies to runtime permissions so it applies to the new POST_NOTIFICATIONS permission. Expect that an app will lose this permission as well if it is not used for some time, so it will need to request it to get it back.

The post Dev Blog: What Developers Should Know About the Notification Permission in Android 13 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.

Listen to the full interview

The post Phunware’s CEO Interviewed for Association for Corporate Growth Virtual Luncheon appeared first on Phunware.

“Today we are pleased to share our trailing financial results for the Company, which included a dramatic year-over-year revenue transformation from one-time, non-recurring application transactions revenue to annual and multi-year recurring platform subscriptions and services revenue tied to the licensing and use of our Multiscreen as a Service (MaaS) enterprise cloud platform for mobile,” said Alan S. Knitowski, President, CEO and Co-Founder of Phunware. “More importantly, and specific to the subsequent events and recent operational actions taken to address our go-forward business activities while the ongoing COVID-19 coronavirus pandemic continues to unfold worldwide, we have announced a $3 million structured debt financing to address our balance sheet and a furlough of 37 Phunware employees to address our cost structure during the existing governmental stay-in-place orders unique to our business facilities and operations in Central Texas, Southern California and Southern Florida.”

Read the full article from Proactive

The post Phunware Announces 2019 Earnings and Business Developments appeared first on Phunware.

“We are living in unprecedented times as the world faces the COVID-19 pandemic, so we are honored and fortunate to have Blythe serve as Chair for Phunware’s Board of Directors,” said Alan S. Knitowski, President, CEO and Co-Founder of Phunware. “Blythe’s proven leadership and experience will be invaluable to helping Phunware navigate the current macro and health environments as we continue to diligently manage cash and drive towards self-sufficiency through operational excellence.”

Read the full article from Proactive

The post Blythe Masters Appointed as Phunware Board of Directors Chair appeared first on Phunware.

“We have built a data engine that is capable of managing over a billion active devices and four billion daily transactions, while generating more than 5 terabytes of data each day,” said Randall Crowder, COO of Phunware. “We can leverage our technology to identify and track critical medical assets like ventilators, but we need to act now and we need everyone’s help getting the word out to medical professionals on the frontline so that we can collect the information that we desperately need.”

Read the full article from Proactive

Visit the National Ventilator Registry

The post Phunware Announces Launch of its National Ventilator Registry appeared first on Phunware.

Read the full press release

The post Phunware Announces Issuance of Senior Convertible Notes appeared first on Phunware.

“Phunware is honored to have an AVIA Vetted Product, which will allow us to connect with over 25 distinguished health systems who are committed to digital transformation in a mobile-first world,” said Randall Crowder, COO of Phunware. “We look forward to this partnership with AVIA as we continue to offer health systems an enterprise-wide, best-in-class digital front door.”

Read the full article from Proactive

The post Phunware Recognized as AVIA Vetted Product appeared first on Phunware.

“The enterprise rollout of this mobile application enabled by our location-based services is another great example of leadership in healthcare innovation and we’re proud to play our part in building a true digital front door,” said Alan S. Knitowski, President, CEO and Co-Founder of Phunware. “Being able to navigate a complex facility easily makes hospital visits less stressful for patients, while being able to reach and inform patients with the push of a button, saving precious time and increasing staff efficiencies.

Read the full article from Proactive

The post Phunware Location Based Services Deployed at A Leading US Health System appeared first on Phunware.

“Over the past year, we have strengthened our financial position as we approach operating cash flow breakeven and move towards breakeven on an adjusted EBITDA basis,” said Alan S. Knitowski, President, CEO and Co-Founder of Phunware. “To ensure we capitalize on these important milestones, we look forward to working with the team of professionals at Hayden IR to help us target and expand our investor audience and ensure we are communicating effectively with Wall Street.”

Read the full article from Proactive

The post Phunware to Launch Investor Relations Program with Hayden IR appeared first on Phunware.

The Company also recently released new user activity audiences capabilities to its Multiscreen-as-a-Service (MaaS) platform that allows brands to create custom user segments, calculate approximate audience sizes and create cross-platform campaigns among users.

“Phunware has been delivering everything you need to succeed on mobile for over a decade, so helping brands engage audiences with digital media is a natural core competency for us in a mobile-first world,” said Luan Dang, CTO and Co-Founder of Phunware. “Our data-enriched media allows brands to optimize their marketing spend, while our blockchain-enabled data exchange provides improved transparency to combat ad fraud and ensure both brand and consumer protection alike.”

New customer wins included Samsung, Live Nation, Ticketmaster, House of Blues, AEG, Madison Square Garden, Metrolink, Coast Electric, Census 2020, the University of Pennsylvania and Truthfinder amongst others.

Read the full article from Proactive

The post Phunware Talks New Customer Wins for Application Transactions appeared first on Phunware.

“MaaS provides our customers with a true digital front door for their patients and staffs, either end-to-end as a complete turn-key solution off-the-shelf, or as software components and tools that they can license, incorporate and build on their own through convenient and frictionless Github downloads and a comprehensive learning management system known as the Phunware Phenom Certified Developer Program,” said Alan S. Knitowski, President, CEO and Co-Founder of Phunware. “Missed appointments cost the US healthcare system more than $150 billion every year, so we’re extremely excited to enable such a prominent, globally recognized healthcare organization to better manage their patient and clinician experience across more than 14 million square feet of facilities spread over a 40 block downtown metropolitan area.”

Read the full article from Proactive

The post Phunware Adds Top US Cancer Center as Mobile Digital Front Door Customer appeared first on Phunware.

“We recently announced a collaboration debut between Phunware and Cisco Webex called the On My Way mobile app portfolio for South by Southwest (SXSW) attendees in March in conjunction with the Cisco Innovation Hub at Capital Factory, where I’ll be discussing three-dimensional cognitive workspaces,” said Randall Crowder, COO of Phunware. “The Meraki Marketplace will now provide Phunware an important channel to thousands of Cisco Meraki customers across more than 100 countries worldwide who need the very best LBS solutions for their network environments without the risk of deploying unproven technology.”

Read the full article from Proactive

The post Phunware’s Location Based Services to be Featured in Cisco Meraki Marketplace appeared first on Phunware.

“Companies across every major industry are using technology to transform their businesses and this event acts as a global stage for the latest innovation across these industries,” said Alan S. Knitowski, President, Chief Executive Officer and Co-Founder of Phunware. “We’re excited to meet with innovators and thought leaders in healthcare and elsewhere to explore how Phunware’s MaaS platform and digital front door can better engage new and existing customers, all while driving profitable behavior.”

For additional information on the event, visit himssconference.org/. To register, visit here. To view the full HIMSS20 program, visit here.

The post Phunware to Attend HIMSS20 Global Health Conference & Exhibition in Orlando appeared first on Phunware.

“Cisco is both a valued channel partner and strategic investor, so we are thrilled to announce this collaboration to extend our mobile corporate campus solution with Cisco Webex Room Kits,” said Randall Crowder, COO of Phunware. “Our mobile cloud platform delivers a critical software layer to optimize workflows while providing a more comprehensive and seamless user experience, so it’s a natural fit to go-to-market in partnership with global digital transformation innovators such as Cisco Webex Teams.”

The post Phunware to Partner with Cisco at SXSW 2020 to Demo Integrated Mobile Corporate Campus Solution appeared first on Phunware.

“It’s critical for any public company to have strong, experienced financial leadership around the table,” said Blythe Masters, Board Member and Chair of the Audit Committee of Phunware. “We’re thrilled to welcome someone of Todd Ruppert’s stature to the Phunware team.”

Read the full article from Proactive

The post Phunware Appoints Todd Ruppert to Advisory Board appeared first on Phunware.

Read the full article from Proactive

The post Two Pediatric Healthcare Facilities Deploy Phunware-Enabled Digital Front Door appeared first on Phunware.

Read the full article from Proactive

The post Phunware Audience Targeting Yields Successful Results appeared first on Phunware.

The Company’s Hospitality Solution not only guides guests throughout each property with real-time and static wayfinding, but also supports additional capabilities including on-demand ordering, contextual messaging, streamlined workflows, third-party integrations and rich analytics to better optimize any mobile strategy or initiative.

Read the full article from Proactive

The post Phunware Drives Digital Transformation for Globally-Known Luxury Casino Hotel appeared first on Phunware.

The Company has made several significant improvements and new product capabilities within its Location-based Services, Mobile Engagement, Content Management, Analytics and Audience Monetization modules that were both highly anticipated and requested, and they plan to carry that same momentum into 2020 with updates that continue to enhance their platform and bring powerful mobile application and mobile data capabilities to their customers.

Read the full article from Proactive

The post Phunware Announces 2019 Product Deliveries and 2020 Roadmap for Multiscreen-as-a-Service Platform appeared first on Phunware.

I asked the team to weigh in on the highlights from this year while the excitement is still fresh in our minds. From new features to on-site sessions, we’ve covered quite a bit of ground. Here’s what you need to know, from our team to yours, about the future of Android as shown at Google I/O 2018.

The new Material Sketch plugin, demonstrated.

“I enjoyed the inspirational sessions this year, especially ‘Designing for Inclusion: Insights from John Maeda and Hannah Beachler.‘ Seeing two leaders in the design field talk about their experiences and take on the industry was motivational. I am also excited about the new material theming as part of Material Design 2.0 as it enables us to push Android design and brands to better align with their brand guidelines.”

—Ivy Knight, Senior UX/UI Designer

Slices, demonstrated.

“I am really excited about the Navigation library and Slices. Navigation will eliminate a ton of brittle code that we commonly write for Android apps, and I am looking forward to updating Phunware’s App Framework to integrate with it. Slices is really interesting, as it will help our users re-engage with apps that they may have forgotten about. It also enables some really cool use cases such as searching for a doctor’s name and being able to offer the user routing straight to that doctor in a hospital app.”

—Nicholas Pike, Software Architect Android , Product VS

Alex Stolzberg & Nicholas Pike

“I was really excited about the new WorkManager that allows for easy background processes to be performed. You can also easily chain and sequence jobs to make the code very clean for a large amount of processes rather than having a cumbersome nested callback structure, reducing the possibility for bugs when writing features or making changes later on.”

—Alex Stolzberg, Software Engineer Android, Product

L to R, Nicholas Pike, Jon Hancock and Ian Lake. Ian is a former Phunware employee turned Googler who stays involved both with his former coworkers and the larger developer community.

“I’m very excited that Google is taking an opinionated stance on development architectural patterns. Writing apps for Android has been a wild west for years, and having some direction and guidance directly from Google will result in new Android developers entering the field with a greater understanding of how to build complete, stable apps. When those new developers find their first jobs, they’ll be more likely to be comfortable and ready to contribute quickly.”

—Jon Hancock, Software Architect Android

Ram Indani and Romain Guy, an Android Graphics Team Manager, at the in-person app review session.

“I really liked the app review sessions. It shows that Google cares about the applications being developed and is willing to work with the community to improve them. Feedback received from the reviewers is valuable and they ensured that the Googler reviewing the app had expertise in the apps they were reviewing.

—Ram Indani, Software Engineer Android

L to R, Alex Stolzberg, Ram Indani, Nicholas Pike and Duong Tran.

“I am excited about what the new Cast Application Framework has to offer. Some of the benefits of the new framework include simpler code implementation and ad integration as well as enhance performance and reliability. Also, new features such as Google Assistant with voice command are automatically included. I was amazed by the Cast Application Framework team’s willingness to work with developers to create unique solutions for our client’s business requirements, such as providing a custom framework and unique branding options.”

—Duong Tran, Software Engineer Android

Want to stay up to date on the latest and greatest in mobile news? Subscribe to our monthly newsletter!

SUBSCRIBE TO THE NEWSLETTER

The post Phunware Team Takeaways from Google I/O 2018 appeared first on Phunware.

Here at Phunware, we are dedicated to making accessible and beautiful apps for an international audience, spanning all languages and locales. We also promote continuous learning for our developers and sharing our knowledge with the developer community. With that purpose in mind, I’d like to pass along a few tips and tricks I learned at DroidCon Boston 2017 that make it easier to adapt your Android apps to reach more users worldwide.

1. Apply automatic right-to-left (RTL) layout support

Languages like Arabic, Hebrew and Persian are written from right to left, which requires a different layout from left-to-right languages like English and Spanish. With the newer Android SDKs, you can skip the step of providing those RTL layouts separately.

MinSDK 17+ automatically updates layouts for RTL with the following:

• In your AndroidManifest.xml, specify supportsRtl = true.

  

  • With this setting, Android will update layouts for RTL automatically when the system language calls for it.
• Use start and end in layout attributes rather than left and right to get the appropriate automatic RTL changes.
• Remember to add margins on both sides / ends of your layouts.

MinSDK 19+ automatically handles RTL mirroring of vector icons with the automirrored attribute:

• Define which icons should or should not be mirrored with RTL (for example, the search icon).
• Reference the Material Design docs for suggestions on what should or should not be mirrored.

2. Prevent grammar issues by using strings.xml with placeholders for arguments instead of concatenating strings

Because grammar is different from language to language, developers cannot assume sentence structure. Rather than concatenating strings together, use placeholders in strings.xml for arguments (Ex: %1$s, %2$d), so your translation service can specify the grammar properly. Also, make sure your translation service understands that they should leave these placeholder values untouched.

• To help translators understand placeholder values:
• Specify a placeholder argument name (id="color").
• Provide a placeholder example (example="blue").

3. Use <plurals> to handle one-to-many results

This little trick will save you time and hassle (it’s also a suggested Android practice), and it makes for cleaner code. Here’s how it looks:

• Warning: some languages do not have the concept of plurals. You will have to adjust your plural definitions for those languages accordingly.

4. Speaking of strings, avoid using Spannables to format strings that will be localized

Again, since sentence structure and grammar can change from language to language, the placement of the formatted part of the string might not necessarily be where you’d expect. If you must use a Spannable, don’t use hardcoded indices to format characters (bold, italic, etc.)—you might just BOLD something that makes no sense at all. Instead, programmatically find the parts of the string to format the characters.

Instead of Spannables, you can use:

• HTML formatting in strings.xml (ex: <b>Hello</b>)
• Html.fromHtml(String text)

5. Use the “German Test” to check text bounds for truncation or bad layouts

Sometimes, localized text can extend beyond the bounds of your layouts—not good. To check for this, use German. It’s a useful test language for this issue because English-to-German translations result in text expansion of up to 20%, with compound words replacing multiple-word English phrases. At the same time, German uses relatively few special characters, so you’ve got a relatively “pure” test for text bounds.

6. Use the Fastlane Screengrab tool to streamline localization QA

This new tool automates the capture and collection of screenshots across each localized screen in your app, uploading each one to a folder where QA can easily compare and verify each version. Here’s how to use it:

• First, write espresso tests to go through each screen in your app.
• Then, set up Fastlane Screengrab to take a snapshot of each screen the tests go through and upload to a folder (it can take in several languages, and run against many devices).
• Finally, compare and verify screenshots.

(Image source: Fastlane Github.)

7. Use Fastlane Screengrab and Supply to localize on the Google Play Store

Gather the appropriate screenshots with Fastlane Screengrab, then use Fastlane Supply to push up your store metadata, screenshots and .apks quickly and easily. Use Timed Publishing mode so you can review and make changes before final upload. And don’t forget the Google Play character limits for your app listing. (You might want to create a script to count characters and verify that they are within the store limits.)

Finally, here are a few reminders for any developers working on app internationalization and localization:

• Many languages use special characters that don’t appear in English, so make sure the fonts that you support can handle any special characters needed (not all of them can).
• Default strings must always be defined in the values/strings.xml file.
• Watch out for special characters in your strings.xml that must be escaped (Ex: \', \").
• Keep an eye out for these important Lint warnings:
  • Extra translation (Too many translations)
  • Incomplete translation (Missing translations)
  • Inconsistent number of placeholders (more placeholder arguments in one translation versus another)

I enjoyed sharing these tips with the rest of the Phunware development team and I hope they’ll prove just as useful for you. Want to join us? Phunware is always looking for curious and creative developers who want to work at a company where mobile is top priority. Check out our open positions and let’s get busy changing the world.

This blog post was made with the permission of Phil Corriveau (Intrepid), who presented the class Bonjour, Monde: Optimizing Localization at DroidCon Boston 2017.

Want to learn more? Subscribe to our newsletter for monthly updates on mobile technology, strategy and design.

SUBSCRIBE TO OUR NEWSLETTER

The post Going Worldwide: 7 App Localization Tips for Android Devs appeared first on Phunware.