I have an application (not a game) and the application store some data in server database for the user, so I need a user id to work with.
Since I cannot have a permanent id in ios devices now, I used the google play games login approach.
The user opens the application and gets redirect to safari where he logs in google and returns to the application and I use the google play games ID for identifying my user.
My binary got rejected because of this, so I can use the iOS game services, but it's not a game, so I'm worried to get rejected again, any one used ios game services just to get an identifier for the user in a non-game app before?
Here is the reject message
We noticed an issue in your app that contributes to a lower quality user >experience than Apple users expect:
Upon launching the app, a web page in mobile Safari opens for logging in, then >returns the user to the app. The user should be able to log in without opening >Safari first.
Any other approaches to get an identifier for a user without having to open a browser window at launch?
It will be best if the user does not have to enter a username or password for registration.
Any help is greatly appreciated.
This is a common scenario on iOS. Many apps, such as Angry Birds, requires registering with them or using a third party login such as Facebook, or sometimes a Game Center ID, if you want to ensure you won't lose your data upon uninstall of app.
So, it's typical to use the app vendor ID to identify the user server side until the point you have another ID to identify them.
Of course, the vendor ID is reset upon uninstalling/reinstalling the app. The Game Center ID is unique per app, but consistent between installs, so it seems like the Game Center ID is what Apple would prefer you to use.
From Working with Players in Game Center:
Player Identifier Strings Uniquely Identify Players
Every player
account is uniquely identified by a player identifier string contained
within a GKPlayer object. The identifier string is created when the
player’s account is first created and never changes, even if other
information in the account changes. Thus, player identifiers are the
only reliable way to track a particular player. For this reason, the
Game Kit API uses player identifiers wherever a specific player needs
to be identified. If Game Center needs to identify a specific player
in your game, the Game Kit API returns that player’s identifier. Your
game uses a player identifier to retrieve information from Game Center
about that player.
In addition to using player identifiers in your interactions with Game
Center, your game should also use the player identifier whenever it
wants to store data locally about a specific player. For example, if
your game stores data to track a player’s progress (such as on the
device, on your own server, or on iCloud), use player identifiers to
distinguish between multiple players playing on the same device. That
way, if a different player signs into the device, you can immediately
personalize the experience by showing content specific to that player.
Losing progress when uninstalling is standard behavior. Saving progress even after uninstall or sharing progress between devices by registering or logging in is a bonus.
Related
I am new to Swift and is currently developing an Multipeer Connectivity app for a course project. The app also has an online log-in feature that stores each user information in Firebase(the backend support).
Once the app gets wifi connection, I want to have a 'friends list' feature in my app and add other app users to this list from the nearby devices found. So far, the only way I could think of is to associate the peerID with an existing app user from Firebase. However, according to the documentation, peerID seems to be associated with the device itself so if two different users used the same device to sign in, this approach can't really work. Is there a better way to achieve my goal?
In my opinion, it depends on what do you want to go with your application as well as how you develop it regarding your business. One of possibility is that one user as a point of time is just registered one device. So you can provide a simple login screen that users will enter their name then map it with device id and save to Firebase. The username is considered as user id as well. So if they try to sign in from another device, you will check whether or not it existed in the system. if existed, ask them that wish to register this device or not, then update your map (user id and device id) from Firebase.
From your friend list, it is still a list of the username of your friends,in which you can add any nearby devices found.
I have an iOS app that permits people to "claim points." I want to prevent a scenario where someone opens the app on their phone, another instance on an iPad and then submits claims in both places.
Presently the app "registers" as the active instance when it starts up. If a second instance starts, it will take control and any attempt by the first instance to save data will result in a redirect that tells the user not to have two apps open. I have seen some games (e.g. Clash) that immediately inform the user of the first app that they are being kicked the moment that the second app opens.
I can think of two ways to do this: submit a "heartbeat" every few seconds to see if we are still the controlling app (wasteful) and some form of notification to all other apps when a new instance opens. Can standard iOS notifications play this role or are they just for popping up notifications to the user?
Any insight into how to post a notice to all other instances of an app when one instance opens up that doesn't require polling would be appreciated!
You can manage this problem on the server side.
Apparently users have to login or at least, your app auto-login with a unique ID with a server.
If you have an API to receive a claim, you can simply check if an identical claim already exists for this Unique ID and return an error to the second device when that is the case.
I have an app that is uniquely branded for each customer (think restaurants, etc.) I need to have the user be able to click on a link to my server that contains a unique code, stores that temporarily on the iOS device (cookie, etc.) and then directs them to the app store to download the app. Then when it is downloaded, the app grabs that cookie or temp. data on launch and brands the app for that customer. I know this is possible on Android, but is it on iOS?
Downloading the app first and then selecting the brand (or restaurant) is not feasible in this case, as the url wil be shared with other customers of the same business and we want to create a fluid experience, where they won't be able to "see behind the scenes" and choose a different branding.
Thanks
Edit
Thank you for all the replies. We've reevaluated and are considering having the url be opened on the device and grabbing the IP address or another unique id, and saving that along with the correct brand to a database. The app will then connect to the database on launch, and if the IP's match, will brand accordingly. We're looking for a more reliable identifier than IP, however. Now that UDID is deprecated, are there any other identifiers we can use?
I think the design you propose of a webserver link creating the code that needs to be read by the iOS app later is the issue. You should have a solution that is entirely app based. Perhaps you can have the same services on the website be available as one app which then sets up the code in pasteboard. The user then launches the actual app that looks at the pasteboard and skins itself accordingly.
That being said, data can be shared between apps from the same app seed ID by using UIPasteboard in addition to a few other ways.
I use the pasteboard to share info between apps quickly and easily using this class.
You can use identifierForVendor (UDID replacement) to identify individual devices. Are you planning on harvesting those identifiers prior to the end user "registering" the device at the final location? If not you'll never be able to determine which device belongs where.
What about having the end-user logging into your server as that restaurant? It can be a somewhat generic login per restaurant like "Wendys/Wendys5?" and "McDonalds/McDonalds7!" to determine their App Store URL. As long as the password is easy and non-programmatic to guess it would be unlikely they figure out how to register as a different restaurant. You could also do a simple restaurant selection screen coupled with a password specific to each chain but this would expose the user to which other restaurants are using the app. This way you won't have to continually add IPs if they expand locations and can revoke credentials if the login is compromised.
One question, though: Do all of your clients understand that they'll have to have an AppleID tied to each device? You can only shared a single AppleID across 20 devices.
Let's say we wan to have a custom backend for a iOS game that manages user accounts and allows the users to send objects to each other, but we don't want to actually have the user to create a dedicated useraccount for our game. It would be possible to simply use the playerID for the usermanagement, but that would not be secure. Is there any way to use a local gamecenter authentication to also authenticate at a custom webservice?
Currently i ponder about how the game 'pocket frogs' enables the players to send gifts to gamecenter friends. Gamecenter doesn't seem to provide this functionality so i assume they use a custom backend for it, but how can such a backend authenticate the player?
I can't say for sure if this is how Pocket Frogs (PF) does it, but based on the fact that only Game Center (GC) friends who also play PF appear on the neighbours list, I think it may work like this:
When a player first starts the game, they get a user id (a 32-bit int, say) from the PF back end which is stored locally. Once the player has this id it can be stored in one of the GC leaderboards under the GKScore context property rather than the value. As far as I can see, PF automatically adds every player to all of the leaderboards pretty much straight away.
Then when another player wants to send a gift, PF gets the leaderboard scores for all of their GC friends and if they have a valid score they must be a PF player and the context value can be read to get their PF id.
In this way the PF back end gets the correct id, but doesn't need to use their GC id.
Incidentally, I tried out the idea of using challenges for sending gifts, and it can work. See http://www.lrgdigital.com/ofgame.html for the game I tried it with - you have to win a game before you can gift it. It has the benefit that you can send the gift to anyone on your friends list rather than only friends who play the game, but there are some limitations as well.
No. Gamecenter uses apple id and that is off limits for obvious reasons. And if you look into the game center framework, there is a way to get gamecenter friends.
Look here to see how to get an array of friends: Game Center Friend List
I'm trying to figure out whether the users I get from ads will buy in-app purchases frequently enough to justify the cost.
Is there any way an iOS app can tell whether the user has clicked on an AdMob ad in the past? Their Download API only seems to show aggregate data. I'm open to using any other network if they let me do this!
If there's anything in the HTTP request from an ad which would give me the user's magical ISU string, I'd be happy to bounce ads through my own server and implement my own tracking.
Thanks!
AdMob doesn't have any way of querying for this.
I decided to bounce ads through my own server and have the app query it later. If the server finds an ad click which came from the:
Same IP address
Same Device type
Same system version
it will tell the app that it came from a paid click.
Of course the problem with this is that I lose data on some unknown number of ad-click installations. I'd like to know how many I'm losing, but I don't know if there's a way to use AdMob's app conversion tracking together with ads which go to arbitrary URLs.