I have developed an iPhone application for a café. In the application you can order takeaway food and therefore I need a way to be sure that there are no orders in a "fake" name (e.g. a person who makes an order with a strangers name, e-mail and so on)
Therefore I have to make the user confirm the order before it's sent to the café. I am not sure what the best way to do this is.
I have been thinking of setting up an SMS gateway and when an order is placed, an SMS is sent to the the entered phone number and the user will have to send a confirmation SMS back. I am not a fan of this approach, as the confirmation is not happening in the application itself.
Then I got the idea that this might be possible with push notifications. I am not exactly sure how it would work (if you have any ideas on this, please let me hear) but since Apple writes the following in their documentation I do not really dare to rely on this for confirmation.
Important: Because delivery is not guaranteed, you should not depend on
the remote-notifications facility for
delivering critical data to an
application via the payload. And never
include sensitive data in the payload.
You should use it only to notify the
user that new data is available.
Another approach which would be very easy to implement would be to programtically retrieve the user's phone number from the SIM card but I have read that Apple rejects applications which does this.
I would like to ask if you have any ideas how I can do this confirmation? It could be one of the above approaches or a completely new. Would it be possible to do something with the unique ID that the every iPhone has?
Could you do the SMS confirmation, but only once? Keep a link of UDID and phone number pairs, and once a confirmation has been made for a pair then don't request it again? That way, regular customers will get minimal hassle.
Don't forget that the UDID for a phone number, or the phone number for a UDID, may change, if the person gets a new device or a new SIM card: make sure your code supports that.
Another approach is to validate credit card information up front as part of account setup. Then offer the option to pay now or cash n carry. This eliminate 99% of the no shows.
Related
By default, Twilio trial accounts can only send SMS to numbers that are listed as Verified Caller IDs in the Twilio console. These numbers have to be added manually, and require a verification message before they can receive SMS. This is an excellent feature for development, as it prevents accidentally sending SMS to wrong numbers.
My problem, is that I am developing for a client whose account is already out of trial status. I don't want the software in development to be able to send text messages to any number, because there is a risk of sending dev messages to the client's actual customers. However, we need to be able to send to some numbers for testing. Is there any way to turn the trial behavior back on? That is, can we somehow configure Twilio to only allow sending SMS to verfied numbers, even if it is not a trial account?
If this isn't possible, I think I can query the Outgoing Caller IDs resource from my program to verify the recipient number against the list before sending. However, this puts the responsibility back on my development team, and the possibility for mistakes remains. I'd like to be able to block the behavior at the Twilio level.
This behavior is only applied for trial accounts, however I'll pass this feedback on internally.
You'll need to replicate this behavior yourself for your applications using an upgraded account.
As you mentioned, you can query the Outgoing Caller IDs to get the phone numbers you have already verified with Twilio and use that as an accept list.
However, for your use case, you can store and fetch the accept list using whatever way is most convenient for you, like in code, file, database, etc.
Depending on your needs, you could embed this logic directly into your app, or use a single shared library, or create a web API that all other apps have to use to send texts.
Good luck! We can't wait to see what you build!
Update after getting internal feedback.
You can create a new trial account, even with the same Twilio profile, which would give you promotional credits and the same verified Caller ID limits again.
The promotional credit should last you a long time for test scenarios.
I have an interesting situation. For some time I have been collecting an audience based on a single user property. Now it has significant amount of devices included. The audience is for ios devices.
I then sent a notification to that audience and I that see some of the devices receive that notification, some don't. Why could that be?
Experiments show that devices that don't receive the notification, receive a notification targeted to single device only. Also they receive notifications send to all users. That makes me suspect that this is related to audiences. I have verified that at least one device that does not receive the notifications has proper value for the user property in question. However, it is possible that the during the past days device has had varying values for the property, based on the account used for logging in to the app. Sometimes it has had two versions of the same app installed at the same time.
I have similar audience for Android and as far as I can tell, all members in the audience receive the notification.
The audience's are in thousands, so the information is based only on few devices I see around me, plus Firebase and Google Analytics.
From Firebase documentation I learn that "a user is a permanent member of an audience after they are assigned to it", which explains why two opposite audiences combined may be bigger than the total number of users, but it makes it even more difficult to understand why someone having the properties required for the audience would not belong to it.
Any ideas on how to debug this or what could be the reason. Or even better, how to fix this? Since this is production software, I can not send excessive number of notifications to try different things.
While I probably still don't know all of the possible reasons for this, there are at least two things that seemed to have some effect on this in our case and third one that could have been the reason if not correctly understood:
1) Our app did register list of values with single call to setUserPropertyString and in some cases the string did exceed the 24 character limit, which caused the property not to be set and the user/device not to be included in an audience.
2) When sending the notification to iOS app, the "High" prority should be selected, otherwise it is possible, or even likely that the notification does not reach the device.
3) Firebase console texts for combining multiple audiences are not all that clear, especially the "does not ..." texts could be clearer in my opinion. This is what they mean in practice:
includes all of == AND, notification is sent if user is included in all selected audiences
includes at least one of == OR, notification is sent if user is included in at least one of the selected audiences
does not include all of == NAND, notification is sent if user is not included in all of the selected audiences, but user can be included in some of them
does not include at least one of == NOR, notification is sent only if user is not included in any of the selected audiences
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 have a client that needs to have its volunteers purchase an IAP (A data package that is downloaded), then somehow reimburse them. The problem is that there is no easy way to do this that I think Apple will approve of. Especially for over 1500 people. I've come up with several ways of doing this with their pros and cons, which one would be best to implement and does anyone have any other suggestions on how to do this?
1) Have the client send out iTunes gift cards via email. The IAP is $7, and you can't send a gift card less than $10. Also, they would have to send them one at a time, there is no way to send bulk. Not going to work
2) Create gift codes like iTunes gift cards. My client can purchase codes in bulk via IAP (so Apple still gets their money), and store them on my web server securely. I can then implement a system to send all the codes to a single email, or individually to multiple emails. Then the volunteers can use the codes to unlock that single IAP. This would be more work on my part, but easier for my client. Something tells me Apple probably would not approve of this method.
3) Create "Credits" that the client can purchase in bulk via IAP (so Apple still gets their money), then gift either the credits or send the IAP info itself to the volunteers via a p2p bluetooth connection created with game kit. This would be harder for the client, as they would have to send each "Credit" individually. But I think Apple would be more likely to approve this.
4) Have the client send me a list of UUIDs for each of the volunteers devices. I add the UUIDs to a secure list on my server. During the purchase the a check is preformed to see if the devices UUID matches one on my server. If it is, they are marked as "all ready paid" and given the IAP data. I don't know about this one, as the only way I can see the money transfer happening is myself getting paid directly, and Apple being left out (So they probably wouldn't approve of this. I have no problem giving Apple their 30% if I could find a way to get that to work with this.
I'd go with Option 5, and create my own IAP system. Much like Option 3, but bypassing Apple all together. Add a Custom URL Scheme to you application, give it to your client to distribute. When your app is launched by its Custom URL Scheme have it open to a promo code entry page.
Your client would be able to purchase/create codes as necessary via a website that you set up for them. You would then store the codes (or create an algorithm to check generated codes against), and validate the codes as the users enter them.
Then your clients users would enter their unique code and have everything unlocked/downloaded as needed.
I have done a similar set up with promo codes to unlock the full version of my applications so I could create my own promotions, without making the upgrades free for everyone by removing/altering the IAP.