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.

• Gateway-Hosted Group Presentation
  Presenting on Thursday, December 3 at 11:00 AM ET
  Registration: Link
• Benzinga Global Small Cap Conference
  Presenting on Wednesday, December 9 at 3:45 PM ET
• LD Micro 13th Annual Main Event
  Presenting on Tuesday, December 15 at 2:00 PM ET
  Webcast: Link

To receive additional information, schedule a one-on-one meeting, or attend a presentation, please contact Phunware’s IR team at [email protected].

Read the Press Release

The post Phunware Determines December 2020 Financial Conference Schedule appeared first on Phunware.

“We are extremely excited by the opportunity to generate more value for our shareholders from the vast portfolio of patents and data that we’ve built over the past eleven years,” said Tushar Patel, Phunware’s EVP of Corporate Development. “We engaged Stout to leverage their deep industry relationships and to specifically explore creative, non-dilutive licensing, commercialization and financing solutions that are backed by the financial value of our intellectual property, but allow us to maintain ownership.”

Read the full article from Proactive

The post Phunware Appoints Stout to Monetize Intellectual Property Portfolio appeared first on Phunware.

“VHC is excited to work with Phunware to bring a myriad of services into one cohesive mobile app to the VHC community,” said Mike Mistretta, Vice President and Chief Information Officer, Virginia Hospital Center. “This technology will provide ease of access for our patients from scheduling appointments, getting care through remote telehealth services and messaging providers to helping patients navigate to scheduled appointments throughout the VHC campus. Our goal is to provide an enhanced level of convenience and care to our patients.”

Read the full article from Proactive

The post Phunware gains new MaaS contract that will give Virginia Hospital Center Health System a new digital front door appeared first on Phunware.

“The GBMC mobile application portfolio is an excellent example of the digital transformation in healthcare that Phunware can help leading healthcare organizations achieve,” said Alan S. Knitowski, President, CEO and Co-Founder of Phunware. “By leveraging Phunware’s MaaS platform, GBMC now offers a frictionless experience through one stand-alone application portfolio for all of their needs, which is even more challenging and critical now due to the ongoing coronavirus pandemic specific to COVID-19.”

Read the full article from Proactive

The post Phunware Secures a New MaaS Win That Will Give Greater Baltimore Medical Center a New Digital Front Door appeared first on Phunware.

“With the growth and demand that we’re experiencing for our proprietary Multiscreen-as-a-Service (MaaS) cloud platform, we believe that the timing is right to engage an experienced investor relations firm to expand our outreach and communicate our enterprise software story to a wider institutional audience,” said Alan S. Knitowski, President, CEO and Co-Founder of Phunware. “Gateway has a proven track record in helping leading software companies like ours to elevate their profiles within the institutional investment community and we look forward to working closely with their team to broaden the reach of our message and increase the awareness of Phunware’s compelling investment thesis.”

Read the full article from Proactive

The post Phunware Engages Gateway to Lead Expanded Investor Relations Program appeared first on Phunware.

“Real estate companies, real estate investment trusts and retailers are great partners for Phunware because there is a growing trend in favor of mixed-use development blending business, retail and residential living in pedestrian-friendly environments,” said Randall Crowder, COO of Phunware. “These types of complex user experiences demand the kind of tech-enabled mobile engagement that our MaaS platform was specifically designed to achieve, and it’s increasingly clear that the COVID-19 pandemic has greatly accelerated adoption curves for digital transformation on mobile as businesses of all types look to foster Healthy Spaces for their customers to work, live and shop again.”

Read the full article from Proactive

The post Phunware Gains Contract Expansion for Smart Shopper Solution on Mobile appeared first on Phunware.

“The platform approach we took to developing MaaS enables large corporations like Cisco to efficiently distribute our software globally for digital transformation initiatives in mobile environments,” said Alan S. Knitowski, President, CEO and Co-Founder of Phunware. “The Meraki Marketplace enables thousands of Cisco Meraki customers across more than 100 countries worldwide to easily purchase and deploy our solutions to optimize healthcare, government, corporate and higher education operations where engagement is critical.”

Read the full article from Proactive

The post Phunware’s Higher Education Smart Campus Mobile Solution Added to Meraki Marketplace appeared first on Phunware.

“Presidio is a great example of the type of channel partner that we work with because of their thought leadership and commitment to delivering the very best solutions for their customers,” said Alan S. Knitowski, President, CEO and Co-Founder of Phunware. “Baptist Health South Florida is paving the way for what’s possible when a premier healthcare organization embraces digital transformation in order to ensure the very best patient and staff experience whether before, during or after visits to their world class medical facilities.”

Read the full article from Proactive

The post Phunware Closes Contract Expansion for Baptist Health South Florida Through Presidio Channel Partnership appeared first on Phunware.

“As a strategic investor and valued channel partner, Cisco is a natural fit to further integrate their cutting-edge hardware with our patented software to enhance our Smart Workplace solution for global customers worldwide,” said Randall Crowder, COO of Phunware. “With certified integrations like Cisco Webex, our cloud platform for mobile provides a more comprehensive and seamless user experience that will help enterprise customers return to work in a safe, responsible and auditable manner for a post-pandemic environment.”

Read the full article from Proactive

The post Phunware’s Room Presence Capabilities Now Available in its Smart Workplace Solution to Support Cisco Webex appeared first on Phunware.

“SLED customers are ideal for Phunware because these government organizations have a comprehensive selection process and must get it right the first time, so they can’t afford to select unproven partners,” Phunware COO Randall Crowder said in a statement. “We are excited to work with GAIN to help distribute our software to the SLED industry in Texas, where digital transformation is crucial to effectively operating in a post-pandemic environment with government requirements that have never been greater or more mission critical.”

Read the full article from Proactive

The post Phunware Teams Up with GAIN for a Direct Line to Government Contracts in Texas appeared first on Phunware.

“We developed MaaS to enable large corporations like Cisco to efficiently distribute our software globally for digital transformation initiatives in mobile environments,” said Alan S. Knitowski, President, CEO and Co-Founder of Phunware. “Our Smart Workplace solution can help enable thousands of Cisco Meraki customers to not only increase employee productivity and satisfaction, but also to provide their visitors and guests with enhanced brand experiences while onsite, including automated arrival and reception check-ins, health surveys, location tracing, broadcast, geofence and beacon-based messaging and personnel and staff engagement by name, position and department.”

Read the full article from Proactive

The post Phunware’s Smart Workplace Solution Added To The Meraki Marketplace appeared first on Phunware.

“Just as the Transportation Security Administration (TSA) became a necessary part of our travel experience in the wake of 9/11, new safety and security protocols are now necessary across industries to restore confidence and get people back together in person again,” said Randall Crowder, COO of Phunware. “In a post COVID-19 world, we can help corporations return to work, students return to campus, hospitals to re-engage patients and groups and organizations of all sizes to gather, meet and interact again, all while tech-enabling best practices on mobile to keep people safer and more comfortable no matter where they get together.”

Read the full article from Proactive

The post Phunware Releases Healthy Spaces App on Google Play for Android appeared first on Phunware.

“Without access to a platform like MaaS, mobile development is an error-prone task that often produces applications that are both difficult and expensive to maintain,” said Luan Dang, CTO and Co-Founder of Phunware. “Just like Amazon Web Services (AWS) enables companies to standardize their cloud infrastructure on a proven platform with various modules to support key features, we are upgrading our mobile application framework to ensure that our Fortune 500 customers and partners can standardize their mobile and digital transformation strategies on MaaS by seamlessly integrating modules that serve as the core building blocks for a brand new generation of mobile applications, solutions and engagement.”

Read the full article from Proactive

The post Phunware Enhances Its Mobile Application Framework appeared first on Phunware.

“A comprehensive mobile strategy is paramount to efficiently and effectively managing the continuum of care, especially in a healthcare industry that is wrestling with challenges compounded by the ongoing COVID-19 pandemic,” said Alan S. Knitowski, President, CEO and Co-Founder of Phunware. “We have invested more than $100 million in MaaS to give organizations like these a crucial competitive advantage when it comes to driving their digital transformation initiatives and ensuring they see a return on their healthcare investments and outcomes, in this case with children and their parents.”

Read the full article from Proactive

The post Phunware’s MaaS Platform Licensed by Leading Pediatric Hospital 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.

“We are extremely proud of our ability to take customers from idea to scale on mobile in a matter of months,” said Luan Dang, CTO and Co-Founder of Phunware. “These new loyalty solutions on MaaS have been instrumental to enhanced mobile user activation and engagement for all of our customers and we are especially thankful to have launched and proven our new technology across several million app users core to the two-party constituencies of the democratic process for the pending election of the President of the United States nationally.”

Read the full article from Proactive

The post Phunware Announces Launch of New Mobile Loyalty Enhancements appeared first on Phunware.

The post Phunware Launches Reseller Program and Co-Sell Partnership appeared first on Phunware.

“California Operation Lifesaver has enjoyed and continues enjoying a great advertising relationship with Phunware. For us, it has been both a rewarding experience and a great value for our organization. As a non-profit, we are always looking for the best ways to get our message out and Phunware has greatly assisted us in identifying the most efficient media options for our messaging,” said Nancy Sheehan-McCulloch, Executive Director of CAOL. “The Phunware team is knowledgeable, professional, flexible and willing to go the extra mile to help us ensure that we get the best service, the best outreach for our ads and success with all our campaigns. Their follow-up and attention to detail are also extremely helpful, providing us with timely campaign results both during and after our media buys and campaigns with the public.”

Read the full article from Proactive

The post Phunware Announces New Projections for its Application Transactions Business appeared first on Phunware.

“Not only does our new customer operate globally with hundreds of thousands of employees worldwide, but it also provides key tax, accounting, advisory and consulting services to the majority of global Fortune 500 companies as well,” said Alan S. Knitowski, President, CEO and Co-Founder of Phunware. “This kind of endorsement for MaaS in such complex, multinational corporate campus environments defines the core value in scale and reach that our software and infrastructure provides on mobile for mission critical digital transformation initiatives.”

Read the full article from Proactive

The post Phunware Announces New “Big Four” Customer appeared first on Phunware.

“We have invested more than $100 million into our enterprise cloud platform for mobile and that full functionality is now optimized for global resellers and other third parties with worldwide distribution,” said Alan S. Knitowski, President, CEO and Co-Founder of Phunware. “Our channel partners can immediately sell mobile software that will allow their customers to maximize unique engagements by tech-enabling their mobile experiences, all while creating new recurring revenues with high margin Software-as-a-Service (SaaS) products and solutions from Phunware.”

Read the full article from Proactive

Become a Partner

The post Phunware Introduces New Channel Program appeared first on Phunware.

“With the South Tower’s completion, and the parallel continuation of the ongoing COVID-19 pandemic, it became increasingly important to provide all mobile applications users at PRMC with highly functional, granularly accurate, real-time routing experiences,” said Alan S. Knitowski, President, CEO and Co-Founder of Phunware. “By leveraging our MaaS platform and its expanded LBS capabilities, Parkview Health now offers a fully frictionless patient and guest experience through one stand-alone app portfolio that provides superior treatment and care amidst the growing and evolving medical needs of their local communities.”

Read the full article from Proactive

The post Phunware’s Location Based Services Continue To Enable as Parkview Health Expands appeared first on Phunware.

“The world is looking for ways to restart the economy and feel comfortable being social again,” said Randall Crowder, COO of Phunware. “We leveraged over a decade of mobile experience to design, develop and deploy Healthy Spaces, so people and businesses will have the tools they need in a mobile-first world to combat uncertainty and gather again in a safer, more responsible way.”

Read the full article from Proactive

The post Healthy Spaces Mobile App Released to Enable Safer Gatherings appeared first on Phunware.