I'm an indie developer and love the platform but have recently discovered that you can't buy phone numbers from a trial account. I've also seen that "sandboxing" is a deprecated feature and was hoping that something similar has been created in it's place. For someone like me money is tight and I'd like to get a basic app together before having to pay for the platform.
Is there anyway that I can test these platform features without incurring a cost?
Twilio employee here.
For development, we don't charge you until you upgrade. That said, to get you started, you get one free phone number when you sign up. It is 100% yours to do with as you wish.. with a couple limitations: You can only send SMS or place calls to phone numbers you've verified with us.
Also, once you've upgraded you can still do testing and development for free with our Test Credentials. The full details are on the site - http://www.twilio.com/docs/api/rest/test-credentials - but this is probably the most important bit for you:
You use these credentials in the same way as your live credentials.
However, when you authenticate with your test credentials, we will not
charge your account, update the state of your account, or connect to
real phone numbers. You can now pretend to buy a phone number, or send
an SMS, without actually doing so.
Related
I have a client who wants to deliver the app to 50k specific users, at start. Then he wants to go public with the app after some time. However, this could not be seen by users as beta testing, since it's just an "exclusive" earlier possibility to access the app, not tests.
We know these users since they are a part of other service users group. We will probably create accounts for them and distribute login/one-time-passwords by invitation or give them the possibility to log in with credentials from the other service.
I've been searching for the solution (e.g. https://www.knowband.com/blog/mobile-app/share-ios-app-without-publishing-on-apple-app-store/) but still, I'm not sure which way to go. We're still in the middle of development so we can provide a possible solution and even make changes in the onboarding/login process. But we have to have a decision on this matter.
From possible solutions:
AppStore - we would not give the possibility to register in the app and just people with credentials could log in. But is it even possible with an iOS app and not be rejected by Apple? I know that many apps don't have registration within the app (e.g. banking apps) - how do they do that? They just say that registration is available only on some www/in person at the bank and you receive credentials to your account somewhere else?
Enterprise distribution - this is probably not possible since users won't be employees of my client. These are regular people.
VPP - I've heard about it recently and never tried it but isn't it just a "simpler" Enterprise solution and shouldn't users be also employees of my client? Can VPP apps be changed to regular AppStore apps afterwards?
I think right now option 1 seem the most possible one since the app will be distributed to all the users after some time (we will add registration then). Any ideas on the matter? How can we not be rejected using solution 1 during a review?
Solution 1 is possible, you provide apple with certs in App Store connect when you submit to the store. Specifically the field 'Sign-in required'
I would do that, it's got very little time overhead as compared to the other two.
So I’m creating an app for a guy who runs a local auction (a mini ebay meets craigslist if you will, but for more in person transactions). I’m doing it as a favor, but to also build my portfolio, so hey we both get something out of it. Now I’m running into a bit of a thinker on the “payment system”. The idea we came up with is when a seller completes the transaction, and confirms the sale, the money is held “by a middle man” until the buyer confirms the item (kind of like how Pay pal can release funds early if the buyer of an ebay item says it’s a good sale).
The client wants it set up this way so that he doesn’t miss out on his cut (10% of the sale)– as in I buy an item, meet the seller in person, then we just do an exchange there having used the app as more of a means to meet. I know Uber charges your card automatically upon GPS once you reach your destination, but it would be better to pull up the “buyer” portion of the app to confirm the sale, thus moving it from the middle man to the seller.
Aside from ensuring the client gets his cut, this can also build confidence that the “sale is funded” when the buyer is on their way.
Anyway, are there API’s out there that can help be build something like this for speedy transactions?
Not sure if this helps, but we will be using Parse as the back end.
Thanks!
There are several payment APIs for the iOS, and I can recommend Stripe which has everything you need. They have an excellent support and documentation for integrating with iOS. You can check the documentation here. Also it works really well with Apple Pay and it's implementation is no brainer.
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 work with a lot of contractors and vendors for mobile app development. They usually ask me to add them to my account and add their device IDs. If they have their own Apple Developer account, I don't think this is necessary. Are they be able to just use their own while developing?
We have an Enterprise account with Apple. We don't do the whole UDID exchange thing for test builds. We build for Enterprise distribution. (We do that because we have hundreds of test devices in geographically disperse locations.) I do give them those signing credentials. Is that enough for a developer to work with?
We deploy the apps ourselves so they don't need credentials for that. They can send us archives to sign.
it really depends on what you want. Truly the developers id should be put under the company account for them to push and also do different security signing measures or app to app talking. However for the rather simple applications this is not necessary maybe around 70% of the time. Something else to think about is who is doing deployment, if you are having a developer or contractor do it for you then absolutely they need your account credentials. As for the device IDs there is no getting around that. You need to add their devices or buy them some because otherwise they are stuck developing on the simulator which does not at all simulate how the application will behave in real life for various reasons.
Hope this helps.
As long as you are responsible for submitting the app to the app store I can't think of a technical reason why developers should be unable to contribute to your app without being invited to join your developer program.
There may however be other concerns or limitations. For example being granted access as a "Member" role is a good way to confirm that you, the client, have accepted Apple's license agreements around pre-release software. Using a certificate issued by your organization to sign builds may also reduce the need to juggle app ids, particularly when testing in-app purchases, and therefore reduce the chance of mistakenly checking in such changes and confusing the team.
I'm starting making an app for a website that I own. I know some about programming with xcode but there's a lot of stuff that I don't know yet. Mostly I have almost everything figured out for the app but I need to add to the app a way to sign in and sign up to the website and also a way to pay with credit card. I don't know how to start with all that.
I have tried to look some videos but I didn't see anything similar to what I want to do. I would really appreciate if you could explain me it, or send me some kind of help.
While I can't help you with sign-up/in features, I do know that ZooZ seems to be the cheapest and easiest way to accept credit card payments on mobile apps.
Both iOS and Android compatible, ZooZ's 3 lines of code monetizes your app in minutes. Users have their choice of checking out with credit cards or PayPal.
The biggest advantages of ZooZ are that your user always stays within your app and won't have to re-enter payment details in the future, resulting in faster processing and higher conversion rates.
Of course you can always build your own credit card processing platform, but considering the challenges of security, merchant accounts, and PCI compliance, it's probably not worth the headache.
Full disclosure: I have the privilege of working at ZooZ :)
Good luck with your app!