Currently, our client's app is in the AppStore, but they want to distribute it to schools and universities. Also, they want the student when opens app first time would be already logged in.
There are tons of info on the internet but it's hard for me to compile it into something clear. As far as I understood first they should enroll in Apple School Manager and rise their own Mobile Device Management. Then devices should be registered on that server. After that server will be sending those commands link. Is that correct?
Also what concerns silent login. The only way to implement it that comes into my mind is to at the app launch send request with some specific data(but what?) and if this is the device under Apple School Manager then return token.
P.S. I hope this is the correct place to ask this kind of question.
Related
I'm seeing the following while trying to sign into Apple Chat Business Sandbox for the first time:
The spinner keeps spinning without any response...
This is happening in both Safari and Chrome browsers.
I'm on and
What's missing?
Contrary to the usual promotional bruhaha made by Apple for a couple of years in a row for its Apple Business Chat Sandbox as a great tool for developers, this seems to be yet another of their software duds.
After a lot (over a month) of back and forth emailing Apple support and experiencing loads of gaslighting and obfuscating by Apple folks of the real state of things, i.e:
I finally asked them directly:
Here's Apple's response:
Perhaps this will serve as a warning for someone looking to implement Apple Business Chat to take their much ballyhooed products with a grain of salt.
I don't think Apple sandbox page is gone.
You still have the documentation at https://developer.apple.com/documentation/businesschat/exploring_business_chat
And the current sandbox env link : https://idmsa.apple.com/IDMSWebAuth/login?isESAEnabled=false&appIdKey=e096fbe1d4b3913a4fa19b9f21a9ad4e58ab71dc3963c5b72a439fb539b6bea6&rv=2
You’ll need a device running iOS 11.3 or later to use the Business Chat Sandbox.
On your iOS device, sign in to Messages using your Apple ID. Go to Settings > Messages > Send & Receive > Apple ID.
Sign in to Business Chat Sandbox with the Apple ID you are using for Messages. A QR code appears the first time you log in.
Scan the QR code with the camera on your iOS device. Then follow the notification on the top to launch a Business Chat conversation with the Business Chat Sandbox.
i am building a website which needs to send reminder messages to iOS (and Android) devices at certain times/dates. So not to a specific app on an iPhone, but to the iPhone itself.
like in the way the reminders app on the iPhone works: even when the app isn't active, reminders pop up.
For the last two days i've been googling on-and-off and reading about apns and firebase etc., but every script and tutorial understandably mentions tokens and id's that you need to receive from Apple and/or Android to get it to work.
One thing i can't find on google is: do i need to have an developer ID or something for this? I'm no xcode or swift programmer, i mainly work with php and query etc. and hopefully can avoid paying yearly for a developer license with Apple or Google.
Hopefully someone can point me in the right direction?
And surely any pointers to a good service or script to use is also very helpful. In the mean time i'll keep digging.
Thanks in advance for any help!
If you want to be able to run your app on an actual device you need to be registered developer, to be able to create certificates and provisioning profiles to sign your app with. You also need to be able to create certificates to be able to send push notifications.
You write that you want to send notifications directly to the phone. This isn't possible. All push notifications must be sent to an app. It doesn't matter if the app is running or not. Which makes sense. Otherwise you would be able to send push notifications to any iOS device out there...
In an iOS application, When I detect a users improper action (for example posting violent content), I wan't to suspend the user from using my application. The basic idea to implement this feature is to create and save an unique id for each application installs and suspend the usage from server api's.
My question is, how can I implement this feature even if the user re-installs the application, and still pass the Apple's iTunes submission?
I came up with two ways to technically implement this feature, but wondering how Apple would respond.
Store the IDFA (I understand that users can reset the id on their behalf)
Store an app generated udid to the Keychain (which should not be deleted even if the user deletes the app)
I know there are no perfect answers, but would appreciate to discuss this issue with anyone that have tried submitting a similar application, or anyone that is well aware of the Apple's guidelines. Thank you.
Apple will reject apps that inappropriately use the IDFA.
If your app does not use server login (at which point, whatever flags you require could be delivered to the client), keychain storage would be the only real solution.
However, if you don't use server login, you block the device, not the user. Is this your intent?
BTW, without server login, a determined user can still get around keychain storage: Reset keychain on the device
You can block a given account. Most people these days key an account with an email address. Some require a credit card (Facebook fully validates accounts using credit card numbers), others require a bank account (PayPal has to send money somewhere!) and it is growing in popularity to request a phone number (Twitter is getting there). In the end, to really be effective, you have to block something that is difficult to produce.
With email, your users can always create a new account. Check out mailinator.com. Alternatively, all you need is one domain to have as many email addresses as you want -- I use five different email accounts daily, and I use about two dozen more on a monthly basis.
Installation ids are ok but users can always just uninstall/reinstall. And if you do manage to get a device-identifying number (easy to do really, even in the post-UDID era) so that you can block a given device, your users can just get a new device, or hack your app to use some random value, or spoof your API with cURL. I own three iPhones, two iPads, two Samsung tabs, three other Android phones, two Mac Book Pros, a mini, two PCs, and I run three virtual Linux boxes, and one virtual XP box. And what happens when somebody sells a blocked device to a non-abusive user?
So just block the user's account, keep excellent log files, and keep fighting the good fight.
I would like to build a mechanism to free my in-app purchases for some of my VIP users devices. My idea is I pre-save the UDID of the user devices in my backend server. When the app starts, it will call my server and get the list of udid and check if the device is in VIP list. if yes, directly show full features without any button to ask for in-app purchase.
However, UDID cannot be used anymore. What should I do in this case? I dont want to ask user to enter some codes. because it would disturb my user interface.
new updates of the question:
The purpose is that , I got a list of people that they will review my apps , but i dont want to have any pop up to ask for promo code or any specific UI for these people. So my idea is I ask them to give me their UDID (or whatever number that they can identify themselves for their phone), and I save them in my backend. When they download the app, the app call the backend and compare their identifier number/UDID, see if they are my VIP, and give them full features automatically without asking promo code and any UI specific for these user.
I would like to identify the user only. Do you guys have any solutions?
thanks
You could do something like provide a URL to the users which opens the app and gives the app some parameter(s). When the app receives these details it could show an alert to ask for a name or some other info (like an e-mail address) from the user. Then you can send the details to your server for verification and set some value in the app to enable the features. In this way the UI of the app is not changed.
I think it's not conform with the iOS/App Store TOS (to be clear).
The easy way is to use the UDID but we can't now... You can get another unique "number" for identifying the device like the Mac Address (you can get in in Objective-C, not really simple but you can).
You can add a button which asks for a promo code (maybe the same button to buy the in-app upgrade). Only those who have a promo code can get the upgrade for free.
Also, should it be "VIP users" rather than "VIP user devices"?
I'm building an iOS app, which provides a service which our website already provides. It's a subscription based service, where all features are enabled when you're subscribed. To get people to sign up for regular payments on the app, it seems like I'll have to go through Apple's in app purchasing API, with auto-renewing subscriptions. That's fine, but the problem is the service users will purchase through the app must also be available on the site. But reading through walkthroughs and the developer guide, it looks like the only way to process transactions is through the app itself, which then can be set up to pass the info to the server. But then I'm imagining this scenario:
User purchases a subscription on the iOS app, goes back and forth between using the site and the iOS app. On the day the user is to be charged, and the days after, they're using just the website, for whatever reason. The server doesn't know they've been billed though, and so features are disabled. In order for the server to find out the user has been billed by Apple, the user has to open the app on their iphone or ipad and sync it with both Apple and my server.
Is there any way for my server to ping Apple directly and get information about the purchases made for my app for a given user? I haven't been able to find anything; the two suggested layouts, with or without server, both use the iOS app as the sole communicator with Apple, aside from having the server verify that information is valid. If it's not possible for the server to get this information first hand, what other possible solution could there be?
Try to not use Apple's built in payment system, and risk getting rejected (with the app duplicating a service that's been available for years online, do we no longer have to use their in app purchasing system anyway?)
If a user is paying through Apple, have the server give them a generous buffer between expected payment dates and when features are disabled (makes the problem happen less frequently but doesn't solve it)
When their account seems expired to the server but it doesn't expect that, email the user a message saying they have to open the app or else their account will not be credited for time purchased (seems like a strange and not really great thing to have to ask a user to do in order to use the service)
This is about all I've been able to think up so far. Anyone have any advice on these solutions, or know of others, or know who I could talk to to try and figure this out?
Yes, you can check on the status of a user's account from your server. There are a few caveats:
First and foremost, Auto-Renewing Subscriptions are reserved for periodicals such as magazines and newspapers. If your app doesn't resemble those, Apple may reject it (as they did mine) and request that you use Non-Renewing Subscriptions (read: Manually-Renewing Subscriptions).
Second: This scenario would require you to store all receipts that you receive on the app, on your server.
Finally: I don't know how your username/password system works, but the user would have to login with the same credentials on your app as they do on your website.
Here's how you check the status of a user's account: Store at least one receipt per user on your server. When you want to check the status, follow Apple's procedure for Verifying App Store Receipts. Send them that one receipt and they'll respond with the latest receipt and the expiration date. Now you'll know, at any given moment, if a person's account is current or not.