I've made an app that connects to BLE Device.
But my app got rejected from appstore review process.
They said I have to send hardware to submit.
How can I submit this for review? Its true that my App can't work without hardware. The hardware does connect over BLE only and is not MFi.
It can also connect to android app.
I just want to get some clarity on what I need to do to get this app through the review process and into the App Store.
Some answers said that their app passed review process by using Video.
But, I'm not sure it works 'cause when I submitted, I included a url of video at memo field.
Actually the video was very short and not included everything.
I'm not sure What am I suppose to do.
I need your help.
------------------Received Text------------------
Hardware required
We began the review of your app but are not able to continue because we need the associated hardware to fully assess your app features.
At your earliest convenience, please send the necessary hardware/accessory to the address below.
NOTE: Please include your app name and app ID in the shipment; failure to provide this information can delay the review process.
Additionally, it may take several business days for us to receive the hardware once it has been delivered to Apple.
Related
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.
I am building out a iOS & Android app. My app may not fully scale to support users and have some limited functionality out the gates. I wanted to put an invite list on the front of registration like Mailbox did a few years ago.
I was trying to read the Apple app store guidelines to creating a "waiting list / invite list" and couldn't get a clear picture. I assume Android is more flexible on this, so I figured I could start with Apple's guidelines first.
Here is what I can find.
In Apple's docs, it says under 3.2.2 "UnAcceptable"
(v) Arbitrarily restricting who may use the app, such as by location or carrier.
In this specific case, I am not blocking by location or carrier. I am just putting up a wall to use the app since some of my users can use it in a limited form, but I can't open it up to everyone on Day 1.
I understand I can run a "testflight" release, but I wanted to make our app available in the App Store for anyone to download since it will be publicly available, just not fully ready for a million people to hit it. My understanding is that the testflight release requires a bit more work based on their docs and isn't as simple as just putting it in the public app store so anyone can get to it.
Apple has the ultimate authority for approving and rejecting apps in their app store so nothing on SO can really be perfect advice. If you are really concerned about approval, you can try to contact apple developers support. Here are a few things I would advise:
Make sure in the developer notes for Apple when you submit to them you include a free account.
In the notes for the app store let the users know that it may take up to __ hours for their registration to get activated.
My understanding is you are doing this to handle the volume of users as you are launching the app. Be advised though that if you start restricting users too much you will possibly get poor reviews. Only restrict usage if absolutely required. If you run into issues make sure you are communicating with the users so they understand.
Good luck with you new app!
Apple just rejected my app saying the following:
"Upon further review, your app's previous submission was improperly rejected for 11.1. Since the sensor functionality of your app is dependent on the associated hardware, it would be appropriate to offer the sensor functionality to all users through achievements or In App Purchase."
Does this mean, I should resubmit the first version because it was ok?
If not, do I have to implement achievements from the Game Center, or what kind of achievements do they mean?
Any thoughts that can help me to get this app on the App Store?
Thank you
Additional information:
first version
In the first version I had "a kind of"-achievement, where users can provide a code they receive with the purchased associated hardware. And they could buy this functionality if they wanted to test for example the device of a friend or a public one.
Rejected: Because they claimed that the user can bypass the purchase of the function by providing a code.
second version
In the second version I took out the In App Purchase because we do not want that our clients need to pay again.
Rejected: see above.
From my experience with the App Store I can say that except for some definite rules (no pornography, hate speech, etc...) most of the review process and decisions are ambiguous and inconsistent.
In fact Apple's App Store policy is vague on purpose so they can exercise a bit of freedom with App rejections. However, from my own anecdotal experience and research, they've always been fair. I have yet to come across an issue where they've rejected an app without having a valid reason for it.
In your case, I believe your app was rejected the first time around since a user could bypass a purchase through purchasing something outside the App Store environment. This means you could sell your code without going through in app purchases and having Apple get its 30% share. This will most likely get rejected again if you submit it.
I'm a bit unclear on what happened with the second case..
My company is working on a dynamic mobile app that updates the look and appearance based on webcalls and we would like to be able to test that it would be able to get into the store okay. For the time being we have used the code to create an interal company app where the initial screen is a logon screen where the users log in with their company usernames and passwords. There are only about 20 people in the company that will be using this app for the beta release and the app logon is only available to members of the company.
We want to have this test release to first ensure that the app gets into the appstore and secondly to get a feel for the app review process. Would this type of app be allowed into the store? Or due to its limited user group, would they reject it? Also would apple need to be given a test username/pass to login to the company website itself to check how the app runs?
Any information regarding this issue would be very helpful!!
From the App Store Review Guidelines (developer account required):
If your App looks like it was cobbled together in a few days, or
you're trying to get your first practice App into the store to impress
your friends, please brace yourself for rejection. We have lots of
serious developers who don't want their quality Apps to be surrounded
by amateur hour.
and
2.9 Apps that are "beta", "demo", "trial", or "test" versions will be rejected
Finally, yes, you are required to provide a "demo account" if a login is required to use the entirety of your application.
Regarding your small user base, your application may not be accepted if it will only be used by 20 or so people (as stated in the comments). The iOS Enterprise Program is intended for in-house distribution (a small and limited user base).
2.22 Apps that arbitrarily restrict which users may use the app ... may be rejected
I have worked for a company that did release apps that were secured by a login screen. All you need to do to get it into the app store is provide Apple with a proper login so that they may test the functionality of the app themselves. When updating the metadata for your app in iTunes Connect, there is a section for testing notes, simply put your test username/password in there for apple to use.
One way they can reject an app is guideline 2.12: "We found that the features and/or content of your app were not useful or entertaining enough, or your app did not appeal to a broad enough audience, to be in compliance with the App Store Review Guidelines." If you're concerned about whether or not your app can get to the store, then there is no real problem in just submitting it. Just don't call it a beta test version because they will reject it. If you want, you can always change the release date of the app to a future date once it passes, and then the app will still not be available to all until that future date is reached. And yes you should provide them with a user name
I am about to submit an iOS app to paypal to get a live App ID. However, the code needs some minor changes. So, I want to know if I can edit my app's code after I apply and get a Paypal app ID? Or, do I have to wait until my coding is done and then submit the app to Paypal?
If your app implementation works well in the PayPal Sandbox, then you are good to go. Most probably PayPal will issue you a Live App ID. All features NEED NOT be entirely functional. Once you obtain your PayPal Live App ID, you can of course make changes to your app, add features to it and fix bugs. Doing so will not void your Live App ID. Keep in mind that any future changes you make to your app will be submitted to the App Store not to PayPal. So technically speaking, PayPal doesn't even know if you made changes to your app or not. The key point here is to make sure your app works well in the PayPal Sandbox -- at all time.
I would also like to clarify one common myth about the Live App ID, for those who are not entirely familiar about what it is. If your App uses the PayPal API, you need a Live App ID before you can test your App on an actual iOS device and/or before you submit it to the App Store. The Live App-ID is provided to you by PayPal, NOT Apple.
To obtain a Live APP ID,
Check your account status. Login to PayPal. Go to your PayPal Profile and click My settings. Confirm that your Account type is either Premier or Business, or upgrade your account.
Check your API settings. Click My selling tools. Expand Selling online if needed and check API access. Click Update and Add or edit API permission or View API signature.
To get your application live, follow the steps outline in Adaptive Apps 101.
Once you've verified that your implementation works correctly in the Sandbox, submit your application to PayPal and you will get your Live App ID.
I assume that by "Paypal ID" you mean "Apple ID that PayPal API uses to identifiy your app", in other words, the numeric ID that iTunes Connect gives you when you set up a new app.
The answer is that iTunes Connect gives you this ID as soon as you set up the app on iTunes Connect (i.e. when you put up the description, icon, screenshots, etc). It's not neccesary to actually submit your app binary to get this ID, and you can change the screenshots and description later, so if they're not ready yet, just upload some dummy placeholders for now.
There should be no problem getting your PayPal API set up with your ID before the app is submitted, but you shouldn't upload your app binary if you still want to make changes (although as it happens, you can reject the binary later and upload a new one if you need to anyway, as long as Apple's not already approved it).