Navigating New Policies for Publishing to the App Stores
Presenter: Chris Daden
CEO and Chief Architect, DADEN LLC
Moderator: Karley Velasquez
Runtime: 28:49
Stuck in the App Approval Process? Review the recent changes to the publication guidelines for both the Apple and Google App Stores to understand how they impact your upcoming App submissions.
Have questions or need advise about publishing your application to the App Stores?
We are always here to help.
Webinar Transcript
Welcome(Karley)
Hi, everyone. Welcome to DADEN Software - Purpose-Built, Software Solutions for the Best Version of your Business.
I'm Karley Velasquez with DADEN Software and we welcome you to today's Virtual Event where we will be covering the most wanted tips on how to get your apps approved by Google and Apple.
With me today, we have Chris Daden, the CEO and Chief Architect of Daden Software presenting you with all you need to know. Chris has founded multiple software development companies and created more than $30 million in software products. After completing hundreds of successful projects using our innovative 7-step development process, Chris knows the ins and outs of what needs to be done to ensure your app’s success. We're sure that you'll have questions, so feel free to type them in during the presentation and we will answer as many as we can at the end.
How are you doing today Chris?
Presentation Roadmap(CHRIS)
Awesome. Thank you, Karley. We'll go ahead and go over a road map quickly. Thank you very much for the introduction. I look forward to talking to everybody today.
With our roadmap today, we're going to spend about 15 minutes covering the following topics first. We will explore some changes in the App Store Industries and we're going to talk about the Apple privacy declaration and how Google will follow Apple as the industry progresses. We're going to cover some example rejections as well as recommendations, and we're going to cover the alternative publication methods if the App Store proves not to be the most advantageous way to distribute your application, but you're still looking to do so.
At the end we're going to do about 15 minutes of live Q & A so feel free to drop your questions as Karley said in the Q&A box and we'll be sure to keep an eye on that and answer those as well towards the end. Thanks again for joining us.
We have some great content today. This is an ever-changing topic even at WWDC a few days ago. Apple announced additional privacy changes that I've gone ahead and updated in our content today to reflect. If there's any proof that this is an ever-changing industry, the fact that they changed it yet again a few days ago is very important to note.
App Store Industries
Let's go ahead and talk about the App Store industry changes. Over the last few years, users have continuously demanded transparency and privacy as more and more consumers become aware of the technology that is in their home appliances, home devices, phones and laptops. Users are really looking to be educated about their data and how that data is used for various application purposes, which is really causing a demand for privacy and transparency.
The Big Data tech companies: Google, Facebook, and Apple are fighting this ongoing battle between the Big Data Tech objectives of monetizing data and providing good functionality to users versus the demand for privacy. I think we see that a lot in companies like Apple, who are creating innovative ways to keep data on devices and doing those things as new product features that they're announcing whenever they deploy a new product. There's this constant battle between Big Data, tech companies and privacy and it's not necessarily a bad battle, it's just a complicated back and forth between the benefits of functionality versus the importance and demand for transparency and privacy. Ultimately what happens is we, as a software development agency, the burden trickles down to our development teams. If Apple requires a new level of transparency or privacy to occur in a mobile app because of the XYZ feature, it actually is up to the development teams to now, add that functionality to the application and bridge the gap between privacy regulation and the end-user. That's what's really unique in these past months to the last year, where development teams are required to implement certain pop-ups to you to do certain things or to meet regulation, and that burden really does trickle down to us, which is why it's important to have these kinds of discussions today.
A fact that we have to complete questionnaires and attestation is also a form of responsibility as a developer. When we submit our application to the App stores, it's critical that we complete the questionnaires truthfully and accurately. That we are attesting the application functionality and the way we handle and store data is in line with what we respond with, and this is pretty unique. It's a new shift in the industry for developers to have to essentially self certify that the application is doing those functions in that way. This is something that we haven't seen before over the past few years. It’s honestly a good thing that has increased participation from the development teams. If the app publisher is promising certain features, functions and transparency to the end user, and when you fill out those questionnaires and attestations where user displayed badges that indicate levels of privacy, which we'll go over later in the presentation.
If you're an app user and you download an application from the App Store you’re able to clearly see what the application does, how it tracks your data and how that easily communicates to the front end user of how you're using their data. We will definitely be seeing an increase in feedback from App users through reviews. We've seen that a lot lately as an agency, a lot of the apps we've produced have had immediate feedback to the app store's. If there was an issue with the permissions that we are requesting or if our agency is requesting too many permissions that may not be relevant to the apps functionality, we can get negative feedback quickly, so it's just something to really keep an eye on. You can tell it's a sensitive topic and you can tell that the security and the transparency of privacy is in high demand because the app users are immediately following through with feedback through the form of reviews.
As a result, we're seeing those reviews, we can predict that user behavior will shift over time as publicity around privacy topics continues to increase. As you see, it’s more in the news as people become more aware of their data and privacy rights. It is guaranteed that user behavior will shift to prioritizing and preferring apps that treat their privacy with a high regard over apps that do not. It's very important that we're keeping an eye on this as developers and just as a general tech community for our user base.
User Feedback
Here's an example of that user feedback.
In one of the applications we have on Android, the ability to manage certain data on the phone, asks for permission to make a phone call. The user was not fully aware of why that phone call pop-up was occurring and quite frankly, we weren't using the phone call permission but our application had it in there. This is an example from within the last days or so, that the user had identified that permission was an overreach, and they've immediately gone to ask if they've provided that user feedback saying that they're uncomfortable giving access to a feature that they don't know the application should use. Once again, being transparent and communicating that to users is becoming of increasing importance.
Apple Privacy Declarations
We're going to focus a lot on Apple today because they're the ones that have really pushed a lot of the boundaries on privacy declaration in the last six months. Google in our opinion, now this is not a fact, but our speculation is that Google will follow Apple’s footsteps like they have been over the years with App Store approval. We believe they will also implement a very similar privacy declaration. But for today, we will focus on the Apple's App Store process because it will glean a lot of insight into what we're looking at as a shift in industry. On the screen here, you can see that there's a new app privacy tab under the publication process for Apple. Until you complete this privacy tab, you will have a field of metadata rejected. For those of you that are developers out there, you will know metadata rejected. Does that mean your app itself is rejected? No, it just means the information associated with your application has been rejected and the privacy questionnaire in the privacy declaration is now a required field. You will have to complete that in order to get your application approved.
Why and What?
Why is Apple collecting this information and what are they collecting? This is a really important thing. This is kind of a definition that we can review. First of all, what do we really want? We all, as a collective community, want customers to understand that data is collected from an application.
There's two ways of using data in an application, according to Apple. You either use it for analytics purposes and marketing, or you use it for functionality. Apple defines collect as referring to transmitting data off the device, in a way that allows you and/or, your third-party partners to access it for a period longer than what is necessary to service. The transmitted request in real time, which is an Apple formal definition. Collect means you're taking the data off-device and you're using it and storing it for longer than you might process within memory. If you're just computing something and returning a value back, that may not meet the definition of collection. Whereas, if you're computing, storing the original data for diagnostic purposes or future uses, it would meet the definition of collect.
There are two ways of collecting and there's two purposes of collecting data. That might be analytics and marketing, or it might be for functionality, either of which you need to disclose. Third-party Partners, according to Apple, refer to analytics tools, advertising networks, third-party, SDK’s or those external vendors, whose code you've added to your app. I pretty much say that this definition of third-party partners in the modern app infrastructure means that all of our apps are subject to this because I don't know many apps that now don't have third-party partners as it’s defined here. We all use firebase analytics, we all use, push notification libraries, we all use data processing libraries, AF networking. All of those libraries we use. It's going to be very difficult to be excluded from this and you really have to be top of mind.
Don’t Forget these cases...
Also, don't forget these cases if your app has a Web View or any of these elements. If you're pulling up a website within your application, you will be within this case, or if you collect and store IP addresses from your users, you'll be included. If your app provides in-app, private messaging between users, that are not SMS text messages, you'll be included. If you use Frameworks such as MapKit, CloudKit App Analytics, which we all do, if you click data to a service request and do not retain it after servicing the request, you're still included. So, there are so many cases that could be applicable to you. It's very important to keep an eye on these cases.
Privacy Questionnaire
Let's quickly go through the Privacy questionnaire itself. You can see in these slides what type of information they're asking about. Apple is going to ask you: Do you collect a name? Do you collect an email address? Do you collect a phone number? Are you collecting a physical address of the user? Any other user contact info that can contact the user outside of the app? You have to actually choose whether or not you collect these pieces of information as it relates to health and fitness. They have a health and fitness category. Are you using fitness and exercise? Are you using healthkit APIs, financial info payments, credit cards, credit score, salary income assets, debts, or any other financial information, you will need to attest whether or not you'll be using that information location and there's two categories here.
This is a very common one, precise location versus course location. If you're a food delivery app and you're tracking a real-time precise location for a driver, then you're going to want to select the precise location option. Whereas, if you're just generally locating a user by geography, Southern California, South Dakota, wherever it is, you'll want to use a course location which has a lower privacy declaration, than the precise location. Sensitive info like race, ethnicity, sexual orientation, pregnancy information, biometrics, if you have contacts in an address book or social graphs. Apple really, as you can tell, does a super specific role in asking you what data is provided because they want to understand exactly what pieces of data you're collecting, and how you're going to use it within the application. Then they're going to create a very user-friendly view at the App Store level that the users see. So they know which pieces of data are used and in what regard.
Pay attention to the usage data section here. If you're collecting analytics data, Google analytics, Firebase analytics, heat maps, any of that information-- if it is tied to a user ID or a device ID, or has any identifiable data in it, then you will be subject to that declaration as well. You're going to be saving contextual data to a user identifier and that's very important to make sure that you declare it. Apple always has this in all of their questionnaires. There's always a catch-all, so any other data types that are not mentioned. This is kind of funny because as the regulations change, Apple will expect you to declare in other data, as required to make sure that the data types that may not be defined today would be included in the future. If it's not listed, think about it. If you're tracking and collecting information, Apple’s definition, you may want to consider adding it in other data types here.
Apple’s Resource
For all that information I just shared, if you want additional Technical Resources, have additional specific definitions, more example cases, or official Apple guidance, which is always great because if your app has ever rejected, you can then, use their official Apple guidance to write back to the reviewers and try to make your case in a formal way. You can go ahead and scan this QR code. If you want to access Apple’s resource directly then it'll take you straight to the website with a document that we find very useful when it comes to all of their privacy regulations.
Rejections & Recommendations
There's two real ways that you're going to be rejected as it relates to privacy right now and this is assuming that your app needs all of the generic Apple guidelines. Like if you're publishing an app in a restricted space or anything like that, there's going to be more things wrong. But generally in our experience with the hundreds of apps that we've produced, we have a metadata rejection because we just simply didn't fill out the Privacy questionnaire or it's incomplete. We normally like to fill that out, alongside our clients so that we're all communicating and on the same page. Metadata rejected means it's probably just missing. The second thing is, if you say yes to any of that tracking information within the Privacy questionnaire, Apple may require additional coding or implementation to make sure that your app has the appropriate privacy pop-ups, to make sure that the user is aware of that functionality. For example, when the app launches, if you're using a webview that has cookie tracking in the website, then you're going to want to make sure that there's a pop-up that says, would you like to allow a data analysis app to track you and track you through other websites. You know there's generic pop ups within Apple’s SDK that you would get permission from the user to do so. If you're missing those, the app review, process can detect that and ask you to add those in and add new-build for further review. These are the two kinds of common rejections that you'll be looking at.
Alternate Publication Methods
If that doesn't work for you, we're not going to talk about it in too much detail today, but the alternate publication methods are important to know. If your app does not meet the Apple App Store requirements, maybe your internally distributing it within your own company, or you're creating custom software for an Enterprise and they're distributing it to their local employees, I'd encourage you to look at the Apple business manager program. This is pretty new, many of you may know that it is referred to as the Enterprise app distribution program. It's now the Apple business manager, where you can have MDM features and distribute apps, privately within your own Enterprise within that new dashboard that Apple has. It's pretty cohesive and then finally is Ad Hoc distribution, which is a great tool for in-house distribution. If I was, for example, at Cisco Inc. at the corporate level, I can distribute a local employee app internally within a private organization, in a private App Store, and that's a form of alternate publication method. You would not need to do the security or the Privacy attestations that are involved in the Apple App Store public distribution because it's a private distribution model. So, keep your thoughts on these as well.
This is a quick chart of the benefits between the App Store and the Apple business manager. You could take a look at this and see some of the benefits. If you're doing in-app purchases, subscriptions, or app analytics, you will not be able to get that through the Apple business manager. If your app requires any of those things, you'll be forced to go through the app store for distribution, especially if your app target download is for customers. You'll want any type of public distribution, to go through the App Store. Apple business manager would not be a good solution if it's beyond your local private distribution.
Then, just a few things on the Ad Hoc distribution. You are essentially self hosting a p-list and an IPA file. For those of you that are developers out there, you know what I mean. The binary of the application that comes out, you'll be posting that within a website or an FTP that users can access from their devices iPhone or iPad. They'll be able to navigate to that and directly download it from your private app store. They will have to trust the Enterprise distribution certificate once it's downloaded, but there's a couple of easy steps to do that. It's really great for internal testing flows. You don't have to get everyone's UUIDs. You don't have to upload it to the App Store. It's just a few steps easier than test flight, but this Ad-Hoc distribution is very good for those kinds of scenarios for distributing, at once again to your own private network of end users that you don't want to use a mobile device management for. Just keep an eye on these alternate publication methods. It's always good to have them in the back of your mind and in the wings, so that you can really make sure that you're using the best publication method.
I hope you found the information valuable today. I'm going to go ahead and pass it back to Karley for our live QA and I appreciate the time.
Live Q&A
(Karley) Thanks Chris, that was great. You had some really great information that you provided to us today. Now it's time to answer a few questions here.
Chris, it looks like our first question is, “What happens if we make the incorrect selection at the time of filling the Privacy assessment out, and what is the process for adjusting those with responses.”
(Chris) Great question.
So the Privacy questionnaire can be modified at any time, as long as you're submitting a new metadata request to Apple. So, it does happen if features change, and you need to adjust those answers. You can readjust them under the app store listing and then you can resubmit them for Apple review with your next build, or with your next approval process. Apple will look at your adjustments and approve the app accordingly. That does happen quite frequently as your app needs change and you can do that any time under the Privacy tab of the app store listing.
(Karley) Okay, great. I know you touched on it a little bit, but do you predict that Google will increase enforcement over time to the extent that Apple has gone to app, approval, review, and privacy transparency?
(Chris) We believe as an agency that based on past years data of how Google as a company has reacted to Apple’s privacy adjustments and App Store submissions that Google will also follow these steps. We think it's necessary for the entire industry to embrace these transparency regulations and communicate those effectively to customers. We do think that Google will follow a similar implementation as Apple. However, as we've seen over the past few years, it may be slightly different or it may be less proactive. It may be more of a self-certification and then a post review process like we would expect from Google app reviews today. However, we do think it will continue to morph similarly to what Apple does. But Apple has clearly been the industry leader in privacy transparency and questionnaires over the past 12 months.
(Karley) Sure, great. Okay. It looks like we have another question here.
“What are the drawbacks and benefits to Enterprise distribution?”
(Chris) The Enterprise distribution model or Ad-Hoc distribution is what it's called now, is that you can only distribute apps internally to your own user base. If you were to try to distribute an app to the public, using the Enterprise distribution approach, you may expect your Enterprise distribution certificate to potentially be revoked by Apple because you'll be violating their Enterprise terms and conditions. Just make sure, as we went over the distribution methods today, that you're choosing the right distribution method for what you're trying to distribute to.
It's sometimes easy to choose the convenient method, right? Ad-Hoc distribution means you don't have to go through the app publication process. It means that you can publish it privately, instant updates, etc. It's very tempting to want to distribute an application that way, but just know that it will catch up with you if you're using it for the wrong purpose. Apple does take this very seriously, so make sure that you are using the regulated channel for what audience you're trying to distribute to.
(Karley) Great. Looks like we still have some time here. Let's go ahead and answer the last couple questions that we do have, “Will Apps be post moderated for privacy adjustment and how frequently will post-approval monitoring by Apple take place?
(Chris) Great question. I don't think there is a formal answer for that. I think that our speculation is that Apple will do automatic retroactive screening of applications, when major privacy milestones occur. However, over the past few years, we have noticed that Apple will kind of wait for apps to expire or need compatibility updates and then that next time the app is reviewed by Apple reviewers, is when they catch a lot of the new enforcement. Apple does do retroactive review in all shapes and forms of regulation, but I'm sure due to the sheer volume of applications on the App Store, that they won't be able to catch all of them. My advice to you is to act like Apple will be reviewing your apps once a month, and if your guidelines and your implementation of your app differs from Apple's best practices or their new policies, make sure that you're proactively updating your application to achieve those latest guidelines, because if you don't, you may wake up one morning and Apple could take your app down and remove it from all of your users, if it does not meet the regulations. We as an agency, always prefer to be proactive and make sure that we are keeping up with the guidelines, even if Apple doesn't do retroactive review. But to answer the question simply, our speculation is that Apple will retroactively review if big guidelines are changed over time.
(Karley) Great. Finally, our last question to wrap up our virtual event for the day is, “Does DADEN Software guarantee app approval if I work with your agency?
(Chris) Of course, we can never guarantee any type of app approval.
However, I will say, of the hundreds of apps we've produced and published, we've been rejected many, many times, but we have never not gotten our clients’ apps approved. Although we don't say we guarantee your app, no matter what, under any circumstance will be approved, we have never had a client of the hundreds of apps we've made of the 500 rejections that I've worked through myself on behalf of clients, we've never not gotten an app approved. So, what we like to do in our Innovation Sessions for every project, is make sure that the nature of the application is within the guidelines of both Google and Apple and only then, if we are within the guidelines we will then move into that wire-framing and planning stage, where the app is actually starting to be created. We would not move into that stage unless we are sure that the application’s nature is likely to be approved by Apple and Android. You can have confidence that it will apply that to your application as well.
Thank You (Karley)
Alright, great. Well, Chris thanks for answering those questions for our participants today. A big thank you to everyone for joining us. We hope that you found our presentation informative.
If you do have any other questions or you need additional specific advice, we're here to help you. Be sure to reach out, we can have a one on one meeting. Keep an eye out for our next virtual event because there is more to come. Thank you everyone and goodbye.
Additional Resources:
App privacy details on the App Store
Apple Developer Enterprise Program
THEVERGE - Why Apple’s new privacy feature is such a big deal