I work for a company that makes kiosk applications. We currently use custom windows tablets for our kiosks, but we're planning to move to using an iPad for all our kiosk apps. We need to have one single app on the app store and the workflow that we show is customized based on client. We identify which client a request is coming from by the iPad's device identifier (udid). We associate this internally with a workflow on the server side and return the appropriate workflow.
So, to recap, we need to create workflows for each single iPad and the iPads are identified by deviceId. A valid workflow is needed by the device to start functioning. Ignoring that the UDID API has been deprecated for a minute, My question then is, does Apple allow this kind of deployment if we publish the app to the App Store?
Another alternate approach we were thinking about was to build a licensing infrastructure on our side. The client would get the iPad, call us for a license key and when the key is entered correctly, we populate our database with the deviceId and a workflow automatically.
Thanks,
Teja.
I would suggest using the mac address of the ipad form the webserver
you would normally present a normal application, you will need to add normal functionality to this application, such as information about the product or the company, or about how to register or buy, you will have to add some usability to it so that apple does not reject your app as being incomplete or a demo
After that you will need to register the mac address of the iPad and authenticate it on the server, if the ipad gets authenticated, then you will present the fully functional application that the kiosk buyers will use.
Hope this will help you
Related
I've written an enterprise iPhone app for the field workers in our company, and the powers-that-be are considering offering it to some of our client companies as a freebie for their field workers to use. I assume that Apple would not allow enterprise distribution to users who are not company employees, so I would have to place it on the App Store.
However, we would like to restrict the user base to approved users or companies, so I would like to avoid making it available to just anyone. The app does communicate with our servers, which makes it something of a risk, in my opinion, of hacking; we'd certainly like to avoid that.
I'm wondering if there is a way to restrict App Store downloads only to certain users or companies? Or is there an alternative method to prevent just anyone from downloading and using the app?
Posting as answer, as per the OP...
For your case, you probably want to look at Business-to-Business distribution: https://developer.apple.com/programs/volume/b2b/
You could use the new "DeviceCheck APIs" that is release in iOS11
Using the DeviceCheck APIs, in combination with server-to-server APIs,
you can set and query two bits of data per device, while maintaining
user privacy. You might use this data to identify devices that have
already taken advantage of a promotional offer that you provide, or to
flag a device that you've determined to be fraudulent. The DeviceCheck
APIs also let you verify that the token you receive comes from an
authentic Apple device on which your app has been downloaded.
https://developer.apple.com/documentation/devicecheck
I want to get some unique identifier to allow specific devices to accessing my API, but looking on internet there's no way to get it and it's against Apple Policy,
But I need to get one of unique ID (e.g IMEI, UDID, ICCID, MEID, ETC)
looking on react-native-device-info, it just have getUniqueID() that can changed
This is IDFV on iOS so it will change if all apps from the current apps vendor have been previously uninstalled.
How can I get a unique ID ios devices?
FYI: My app won't be release into AppStore
There are major privacy concerns when getting a unique ID from a device. You have a few options.
First, you could just add some form of authentication or login system. This could be per device, per user, or even 1 login for the entire API. You could also limit the API to only respond to certain controlled IP addresses.
Second, you could add a flag and have a different version for production then in development. Limiting access that way.
Third, on first launch of your app you could request a new token from your server. The device would then store that token and the server would as well (to ensure no duplicates). Then just take that stored token and send it to the server for every request.
But on the device level there are privacy concerns in unique IDs for each device. You have to build your own system to handle it depending on your needs.
I would suggest that the IDFV was designed to suit your needs, while maintaining some level of privacy.
It is supposed to allow you (a vendor) to identify a return visit while not allowing you (a vendor) to share a user's identity with a third party in a relatable way for the third party to data-mine.
If users are routinely uninstalling and re-installing all of your apps I would look at solving the distribution issue you have there. I would assume (although haven't tested) that an update of an existing app would maintain the IDFV.
I'm building a server-side "push" notification capability for various (specific) iOS apps my company makes. I'm not a mobile developer. I understand there's a "p12" certificate I'd need, and that the mobile client must provide the "token" I use to initiate the push from the server.
Does anyone know if there's a pre-built developer/test iOS app in the store that will display a token, has a downloadable cert, etc., and will accept push notifications? I'd like to build the server-side out a bit before I try to plug in the real tokens/certs for my companies apps.
No there isn't, but there are 2 separated environments one for test and one for production.
Usually the app developer team should provide the certificates to the back end developer team.
Once you have your certificates you can integrate them in the backend.
Pay attention that certificates are app specific, they work only for a given identifier.
During test both the team should work together to see if everything work as expected.
Token can be track in a different way, in debug mode using real device by printing them in the console log or by using a particular configuration file, in both cases the device must be connected to Xcode.
You should ask the dev team if they can provide you a sample app that print the token on the device screen and that just send the token to the server to make your experiments.
Is it possible to create an iPhone App for certain group of users ? Like, can we create some kind of private group on App Store and our clients could go to that group and then the app would be available to them ?
If my app has a start-up page like asking for License/Pin , so could only those users access it who have that Pin , would it be acceptable for App Store ?
Basically I want to set access of my app to limited set of users, so what are my options here ? I dont want to go to 'Enterprise Program' as my users are not employees of my organization they could be any one , any where in the world.
In general the application should be available for everyone, otherwise it will not be accepted for publishing on Appstore. However it is allowed to require some kind of registration, whether is for free or does cost something. It is also possible for a software to require some kind of hardware as well. For example an application that works as a remote control for a media player.
There is no such thing as a group on Appstore.
You could register as an Enterprise. Ther is an iOS Enterprise Deployment Guide Link
As I know you can manage your enterprise devices there and also distribute Apps to your devices without the need to use the AppStore. You need an enterprise distribution profile to sign the app and then users can install your enterprise app via iTunes.
I believe the following post might solve your issue:
http://www.foraker.com/ios-app-distribution-options/
In short, Apple allows you to create B2B applications, where only the selected companies can use the created applications:
https://developer.apple.com/programs/volume/b2b/
they asked me to build an iPad app for a clothes company, the client asked to have the application available only to resellers:
Since I think it is not possible to submit on the app store an app with usage restriction only to few allowed people, I thought about different options:
Bulding an app with some general info accessible by anyone,
and adding a password protected section only for resellers.
Building a password protected web app
What do you think is the best solution?
I've got some doubts about both:
Are Apple reviewers going to approve an app with some password protected content?
Do I need to provide apple the password to access prices information?
If I build a web app, is there a way to cache data to allow the content be accessed when offline? (I noticed that when the iPad is rebooted web app data get lost)
Thanks
Giuseppe
It is likely that such an app will be rejected from the app store because it is for a 'limited audience.'
But, you don't have to release it on the app store, you can instead develop an enterprise app which you can then only make available to your company employees and resellers. You are free to restrict distribution of this app to whomever you want or password protect it as you wish -- in any case it won't be available for download via general app store routes, but your company could make it available on a 'reseller-only' portion of their website for example.
Depending on how complicated you want the app to be, doing a website is another option. You are allowed a limited amount of persistent local storage in a sqlite database (one of the new features of html5), if the app is simple enough, this should work for you.
If the app can have enough general utility (maps to the nearest resellers, for instance), you can submit it to the App store with a demo account (which can have dummy data) for the password protected features.
But a web app that can be turned into a web clipping (custom icon, etc.) for a password protected site is another very good option.