Advertising ID on Mobile

Report · Dec 18, 2017

I don't want to overwhelm anyone with the details of what I am trying to do, but in a nutshell, I am trying to develop a mobile AIR app for real estate agents that is customizeable that they can give to their clients and, and when the client installs it, it will look like the real estate agent wrote it themselves and will have their branding in the app.

To do this, I need to save a unique identifier from any Android or iOS device that installs the app. Apparently, this is inconsistent approach and not supported across all devices, so I can't do something simple like store a MAC address or a UDID because not all devices will allow access to these identifiers, so I would get inconsistent results.

The only consistent identifiers that I have been able to narrow down are Advertising ID's. These are provided by both iOS and Android devices and there are ANE's available that will give you access to these identifiers. What I am concerned with is this - I am not using them to provide Ads to my users. I just need to know who a user is and associate them with a real estate agent consistently.

Does anyone know if Apple or Google will throw up a fuss if you try to submit an app to the app store that uses an Advertising ID, but is not using it to serve up ads???

Thanks for any thoughts!

Report · Dec 20, 2017

At least for Apple this use if the Advertising ID would be against the policy. When you submit your app, you must confirm that you only use the ad ID for either showing ads, connecting ad ids to installs from previously shown advertisements or connect in app actions to previously shown advertisements. For any other uses you should contact the Apple developer support. I don't know for sure but I guess they would not allow your usecase and they would ban your app in case they find out, but again that's only an assumption.

Report · Dec 20, 2017

Yikes!! I can't risk getting my app banned, it is going to pay my bills. I will have to find another solution. Someone else suggested that I might be able to create a temporary value in a cookie that I could use, and then on first run, my app could look up the cookie value in my database to associate the agents branding. I may look further into this as an option.

Sadly, I don't know much about cookies and don't know if stagewebview would have access to the cookies generated in safari, or perhaps to the localstorage used by safari. Please let me know if you know any information about this.

>

Report · Dec 22, 2017

The followings depend on the possible levels of app customizations by your Agents, so you may pick whichever suits you and your app the best.

If the app is compiled differently for different agents, you can define a compile time constant with the compiler. Something like CONFIG::AGENT_ID,1234
If the app is compiled differently for different agents, you can also include an additional config file in the package which defines the id of the agent and attaches the user to it
If the install packages are static and it's not possible to recompile them to different agents, you can inject a file in the packages. Both the IPA and the APK are practically zip files, it's relatively easy to add a new file to the packages with a terminal command. Add a config.json file wherever it's needed, load it with your app and that's it.
If everything is static and it's not possible to create different packages for different agents, you can use Firebase to track conversion events using custom campaigns. This might not be that straightforward and it requires a little bit more effort, but in the end you can see who installed the app from what custom campaigns (assuming you give different campaigns and links to your different agents). It might also require even more effort to download this data from Firebase to your servers, but if your app generates some revenue it's worth it to subscribe to Google's BigQuery. (In our apps we're moving towards Firebase in every aspect, it's real good)
You can save a random generated ID on the device (SharedObject, EncryptedLocalStore), but each time the data is being wiped you lose the ID, so it's not bulletproof (this method is similar to a browser cookie, but more AIR friendly)

Although I'm not sure how your app works, how do you customize the apps so they're available to your agents and their users differently, but depending on those it shouldn't be that hard to "stamp" the users some way.

Maybe a little more detail would be more helpful.

Report · Dec 22, 2017

Only solid way I can think of with a static build:

Give each agent a code, agent's customers enter that code (given by the agent) when app first starts, app uses that code to load externally or grab on disk the relevant assets.

Android has a few more solutions but Ios surely doesn't, and if you need both with one build only then that's what you are gonna end up doing one way or another.

Report · Dec 22, 2017

IGZN and ASWC, Thank you for your suggestions. I will have to look into localstore, but I think that is a possible solution. I do not need persistent information about the users, I just need my app to know who they are from the time they install the app to first run. So if I could hold a random value in localstore for two minutes even, that would work well enough for me.

But after I thought about my business model a bit more, I'm not sure I will take this approach either. See, my app provides a very unique service that is worth money. I don't want just anyone to be able to download it freely, because then nobody will ever pay for it if they can find an agent link and just get it for free.

I'm thinking of making it invite-only. So, I am thinking I may put an "invite" button in the agent app, and by clicking it, the agent will be to enter an email address in a pop-up. This will send an email to a client with an install link, and when they install the app, they will have to put in their email address to verify they have been invited to access the features. This will at least force an agent to do a little work to distribute it to users, will totally eliminate the ability to download the app freely by the general public, and I will limit the number of installs that each agent gets with their subscription to keep them honest. Right now, I think this is the approach that I will take. Localstore will be my backup.

Report · Dec 26, 2017

That model would work for Android but surely not with Ios.

Report · Dec 26, 2017

ASWC, I don't understand why this model would not work for iOS??? I would not be collecting any personal data from a user's device at all. Would Apple not allow an invite-only app in the App Store for some reason???

Report · Dec 27, 2017

I could be wrong of course but I never saw that kind of option in itunes and since ios apps can only be downloaded from the itunes store (not sure if ad-hoc versions can still be downloaded/installed from personal servers) I don't see how your plan is gonna work for ios.

Report · Dec 27, 2017

After a quick check with itunes and term of use it seems that:

- itunes does not offer invite only apps as an option

- Apple terms of service states that it could reject invite only apps (provided by external service) as it might be a way to skip the 30% Apple cut.

Report · Dec 27, 2017

ASWC, thanks again for your reply. I have searched around and have been unable to find the information that you mentioned in the App Store Review guidelines. I was wondering if you could provide a link to the documentation where you found this?? I want to contact Apple Developer Support to discuss this and want to have a full understanding before I approach them.

Thanks for any help you can provide!!!

>

Report · Dec 27, 2017

OK, perhaps I have tried to describe what I want to do without informing you of HOW I actually want to do it.

I want to release an app through the App Store for real-estate agents, not release it myself somehow. I have integrated a subscription service into the app that agents will pay into using Stripe to take credit cards, in an effort to avoid the 30% cut to Apple Using Apple's subscription services. There will be an "Invite" button within the app that when an agent clicks on it, they will be able to enter a clients email address, and an invite will be emailed to the client with a link to the APP STORE to download a "client version" of the app which will be invite-only. When the app opens on first run, they would be required to enter their email address for authentication, and then they would be granted full access to the app features.

So, I am not trying to distribute the app outside of the App Store on my own, I am not trying to collect any unique identifiers on a users device, I wouldn't be using cookies or local storage, so I don't understand why this would be rejected for any reason.

Am I missing something obvious???

Report · Dec 27, 2017

That's an enterprise app, you can do that. You require a different kind of store subscription, cannot do it as a personal developer but only as a company. We just released an app, downloadable from the client website (not the app store), and it gets activated using a code (in this case hardcoded in the app, but I guess there is no difference for you).

I wasn't in charge of Apple bureaucracy (thanks God) just of development, so I can't give you too many kafkhian App Store deails, but it was no problem. Still, you never know with Apple...

Search for enterprise apps.

Report · Dec 27, 2017

Apple Developer Enterprise Program - Apple Developer

Report · Dec 28, 2017

The only thing you are missing is the ability for Apple to reject your app/business model because it's not compatible with theirs. 2 important things to keep in mind:

- they don't like subscription apps (unless you use their subscription program) cos they don't get their 30% but they let you do it if you are a company, have good number of app published, or provide a basic functionality (app can be used without subscription).

- They don't let you publish an app that does nothing (an app that can only be used if you have a code/email/ect ...)

So in your case here's what I see:

The real estate agent app:

- YOU publish it to itunes as free app

- must provide some real functionality without subscription (to avoid rejection)

- include your subscription model

The client app:

- YOU publish it to itunes as free app

- anyone can download it (no other options on itunes)

- provide some real functionality to avoid rejection

- include your client code model

So I think the bottom line is that you'll need those apps to do something BY DEFAULT so you won't get rejected and the client app will be available for download by anyone, that's the 2 main difference with your model.

Report · Dec 27, 2017

Sorry I haven't read carefully what you posted here, yes none of this can work for Ios:

- no download link (it's itunes or nothing)

- no localstore (prevented)

- can't stop people from donwloading the app, app is either public or turned off, no in-betweens

- Apple won't let you make money without their 30% cut, if you insist they will just reject you.

For Android you can do almost whatever you want at least for now.

From what I understand your business model is not compatible with itunes, you want to:

- be the owner of an itunes app

- charge customers for offering a customized version of that unique app < those don't download the app

- customer distribute that customized app to their customers < those download the app

Even if this was technically possible with the itunes ecosystem you would actually be creating a personal and private store within the itunes store which would keep itunes from getting its 30% and there's just no way they will allow your app on their store. You need to rethink your business model completely for itunes.

Report · Dec 27, 2017

Jobs lied in front of the world in order to protect their 30% cut...

they will never make it easy

Report · Dec 27, 2017

ASWC wrote
Sorry I haven't read carefully what you posted here, yes none of this can work for Ios:
- no download link (it's itunes or nothing)
- no localstore (prevented)
- can't stop people from donwloading the app, app is either public or turned off, no in-betweens
- Apple won't let you make money without their 30% cut, if you insist they will just reject you.

Not actually true, you can use the Enterprise Program

to have your own store and provide your own links etc.

Apple Developer Enterprise Program - Apple Developer

That said, all that would still not solve the problem of the OP as the original problem is badly described.

The problem is not about obtaining a unique identifier, it is about who has access to what,
eg. you're trying to re-invent (badly) a login/password system.

Maybe spend a little time of planing before going into assuming a unique identifier gonna "save" your app.

Report · Dec 27, 2017

Never heard of that before, thx for sharing. What about the "in-house apps" seems fairly close to what he's trying to do no?