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.

“Baptist Health South Florida’s leadership is further raising the bar for digital transformation in healthcare, truly tech-enabling the entire patient experience at their facilities,” said Alan S. Knitowski, President, CEO and Co-Founder of Phunware. “We are thrilled to support a channel partner like Presidio, who is committed to ensuring that BHSF is able to effectively implement cutting-edge technology standardized on our MaaS LBS software and mobile infrastructure.”

Read the full article from Proactive

The post Phunware to Expand Location Based Services Software Coverage at Baptist Health South Florida 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.

“Our hearts go out to everyone directly affected by COVID-19, but we are just as concerned about the untold toll this pandemic is having on small and midsize businesses nationwide as they scramble to adapt to emerging state and federal guidance,” said Randall Crowder, COO of Phunware. “Our enterprise cloud platform for mobile is uniquely suited to help them not only adhere to these guidelines, but also to engage and manage customers in a mobile-first world that is rapidly becoming mobile-only.”

Read the full article from proactive

Sign up for the Phenom Certified Developer Program

The post Phunware Offers A Free 60-Day License Of Its Mobile Engagement SDK appeared first on Phunware.

“We think it is extremely important for our country’s mayors and city officials to think globally, but act locally during the current COVID-19 pandemic,” said Alan S. Knitowski, President, CEO and Co-Founder of Phunware. “During such trying times, we believe it is critical for local communities to take swift and decisive action from the bottom up to supplement government efforts being led from the top down at both the federal and state level, including a cogent go-forward plan for addressing the needs of citizens and visitors to each city nationwide in safely getting back to a more normal cadence for their personal and professional lives.”

Learn more about the Smart City Pandemic Response Solution

The post Phunware’s Smart City Solution Launches 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.

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.

Read the full article from Proactive

The post Phunware Unveils First National Railway Customer for Mobile Corporate Campus Solution 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.

Phunware will be implementing its Multiscreen-as-a-Service (MaaS) platform for Fortune 50 company with partner LTTS. Crowder explains how enterprises can Phunware’s location-based services innovations for corporate campus.

Read the full article from Proactive

The post Video: Phunware Deploying Its Location-Based Mobile Services to a Fortune 50 Company’s Campus appeared first on Phunware.

Have you ever been to an all-you-can-eat buffet? Giant appetizer platters, vats of soup, an endless selection of meats and veggies and desserts…it’s tempting to load your plate up with items that don’t even sound that appetizing. “It’s right in front of me—why not?” is the prevailing mentality (at least for gluttons like me). Of course, by the time the meal is over, you might as well roll me out of there. I will have eaten too much—without even enjoying a lot of it.

Right now retailers are at their own all-you-can-eat buffet of sorts. They have more options to engage customers than ever before. They have an array of technology tools they hope to use to nail marketing personalization once and for all, driving conversions and setting them apart from their competitors. There’s the standard fare, of course (email marketing, direct mail, PPC, etc.), and a few new gourmet options as well (native app push notifications and SMS alerts, geo-targeting, etc.). And retailers are pigging out.

They’re trying everything on the menu to deliver targeted offers to consumers, hoping to catch them at the right moment with the right message to make them to open their wallets. They’re sampling everything in the buffet…and leaving with nothing to show for it. In fact, over 60% of retailers say they expect ZERO ROI from so-called personalized messages they’ll be sending this holiday season. Talk about empty calories!

If the majority of retailers have no confidence in the return they’ll get on one-to-one mobile push marketing, we’ve got some work to do as an industry. Fortunately, through their loyalty programs, many retailers have access to the detailed shopper data that can make personalized marketing personalization effective. Add that to the data from consumers using the retailers’ branded mobile apps, and they have what they need to paint a pretty complete picture of their customers.

So what should retailers be doing with that data? Let’s start with the basics.

Bad Mobile Marketing Personalization: What Not to Do

A personalized offer can surprise and delight a customer (“Wow, this brand really gets me!”), or it can completely freak a customer out. Avoid creepy “I know what you did last summer” personalization.

Example: Customer has purchased two bottles of wine every night for the past three nights.

Not cute.

Also, if you’re going to use one-to-one marketing, make sure it’s actually personalized—not obviously programmed. Consumers catch on when they receive marketing messages from brands at the same time every day or week, and they learn to tune them out.

Example: No data collected.

This offer may as well say “Click here for something boring.”

Good Mobile Marketing Personalization

Good personalization leverages user data and context to deliver messages and offers that benefit users in some way—educating them, informing them, giving them discounts and promotions, or simply entertaining them. Segmenting app users and personalizing content according to the specific characteristics of each segment is a powerful way to keep users engaged.

When you layer this segmentation with location targeting capabilities, you’ve got the magic sauce. One location targeting tool is the geo-fence—a virtual GPS boundary used by marketers and advertisers to trigger campaigns and measure activity. To put it very simply, when someone with your brand’s app on their phone crosses through a geo-fence you have drawn around your store location (for example), it might trigger a message or promotion. Here are some examples of the types of high-converting mobile marketing messages you could deliver:

Example: Getting Creative with Geo-Fences
Data trigger: User has crossed through a pre-established geo-fence…

In-the-moment, contextually triggered marketing outreach like this just feels more relevant to the user—because it is—and it may even be welcome. (After all, who doesn’t love turtlenecks?)

Download our eBook, Capitalize on Context: The Savvy Retailer’s Guide to Location Marketing, to learn more about how mobile technologies help you understand and predict consumer context behavior.

DOWNLOAD THE eBOOK

Measuring the Effectiveness of Personalization

Some users are always going to be creeped out by personalized marketing and will resist the urge to share data with you in exchange for a more tailored marketing experience. That’s ok. You’re marketing to the users who do want personalization, and the only way to figure out what works is to test it.

An important indicator of good personalization is the number of users who re-engage with your app after receiving personalized communication from you. Whether your outreach is via push notification, email or something else, make sure you have a clear and succinct call to action that draws them back into your app. Tracking how many users take that call to action will validate that your messages were user-centric and not generic or irrelevant.

Tailoring push notifications and other marketing messages to your app users is not only about personalized content—it’s about the right context, too. Analytics are your best weapon for defining the best time, place and message to engage your app users. Keep in mind that the right context will vary from app to app, and will ultimately be decided by the users anyway.

The moral of the story: if you don’t want to end up among the 60% of marketers who expect zero ROI from their mobile marketing, don’t pig out at the all-you-can-eat mobile marketing buffet. A carefully planned, data-backed personalization strategy is your best bet for recouping that marketing investment—and then some!

Want to take the guesswork out of calculating ROI? Use our free Marketing Automation ROI Campaign Calculator to find out how much automation can save your team.

Take Me To The ROI Calculator

The post “Click Here for Something Boring”: When Marketing Personalization Falls Flat appeared first on Phunware.

Amazon’s forays into brick-and-mortar stores are all over the news lately, with many analysts predicting doom and gloom for traditional retailers across the country. While retail brands are wise to be concerned, we’re here to point out that this turning point actually represents a big opportunity.

By embracing mobile in a whole new way, traditional retailers can expand their business models and change the game on Amazon. Mobile’s unique location technologies can turn local brick-and-mortars into hyper-personalized and highly nimble distribution centers for customers’ online orders. With the right mobile solutions, local stores can deliver faster and better than Amazon—and customers will reward them for it.

Mobile Can Turn Local Stores into Faster and Better Distribution Centers

We’re all accustomed to using location-based services for mapping and navigation. Warehouses and large distribution centers commonly use real-time location systems to keep track of inventory. Mobile gives retailers the power to combine navigation with the ability to find and track individual pieces of merchandise—within the footprint of a local store—and puts it all right in an associate’s pocket. As you’ll see, this enables local stores to deliver for local customers, faster and better.

What you need is an associate-facing mobile app with the following features:

• Barcode scanning that integrates with your inventory system
• Mapping and wayfinding with indoor blue dot navigation

This mobile app would interact with an in-store Wi-Fi network or beacon system to locate products and streamline operations, so the store can put products in customers’ hands as fast as possible.

DOWNLOAD THE RETAIL STRATEGY KIT

Use Case: BOPUS (Buy Online, Pick Up at Store)

Shopper Jane purchases an item online that is available at her local SportzStuff store. She decides to pick it up on her way to work, rather than wait for delivery. Associate Bob uses the associate app to locate the item, then navigate the quickest route to collect the item and return to the stockroom for packaging. When Jane arrives at the store 15 minutes later, everything’s ready for her—that’s faster than Amazon.

What’s more, if the retailer’s app also has a customer-facing side, Associate Bob can receive an alert the moment Jane approaches store (mall, parking lot, etc.). That alert enables Bob to greet Jane by name at the door or even curbside, so he can present Jane’s purchase to her personally.

Not only is this approach faster, it also provides a more satisfying customer experience. Shopper Jane got exactly what she wanted with VIP treatment and little to no hassle, the same day she wanted it. If she wanted to try on the item in-store for size, she could do so quickly and make any necessary return or exchange conveniently—instead of having to find and schlep to UPS or an Amazon vault. Plus, stopping by the store gives Jane a chance to make an impulse buy or two.

Use Case: BOSFS (Buy Online, Ship from Store)

Shopper Latrelle also purchases an item online from SportzStuff. It turns out that item is available at the store just across town, so Associate Jeff uses the store’s app on his phone to locate the item in the right color and size, then navigate by the fastest possible route to collect the item and return to the stockroom for packaging and shipping. Because Jeff got the product out as fast as possible—and it was sent locally instead of from a regional distribution center—SportzStuff can beat Amazon again.

Use the Advantage You Already Have: Proximity

Think about it: As Amazon rolls out its brick-and-mortar strategy, it will have to procure space, build out, stock and staff stores across the country. Thousands of retailers already have those physical stores, close to their customers. Unlocking their potential with a mobile app can take as little as a few weeks—and Amazon can’t hope to beat that.

Mobile has so much to offer retailers. Want to learn more about leveraging a mobile app to improve the customer experience and drive sales? Download our Retailer’s Mobile Strategy Kit. And if you’d like to talk about challenging Amazon by expanding your business model, contact retail@127.0.0.1.

WATCH THE ON-DEMAND WEBINAR

The post How Retailers Can Use Mobile to Out-Deliver Amazon appeared first on Phunware.