Publishing to the Apple Store and to the Play Store #480
Comments
|
@stephhuerre I have not had a lot of issues with Apple's review process recently. If you are using gmail login, you may have issues with apple sign in not being supported. I have not yet updated e-mission to support apple sign in (#465), so if that is a blocking issue for you, you may want to implement it yourself and submit a PR. If you would like somebody on the e-mission side to implement it urgently, I can ask @sunil07t if he has some spare time over winter break.
The apple reviewer comments were only that we needed to add the line "tracking location in the background can have significant impacts on battery life". They will require you to add that to the app description as well. The medium accuracy setting was actually in response to user feedback. As you can see from section 7.2 of my thesis, the frequency (1 meter v/s 30 meters) makes no difference to the power drain on iOS. The only setting that does lower the power drain is medium accuracy. If the users had a long commute (~ 4 hours round trip) then the high accuracy data collection resulted in unacceptable power drain, and they would uninstall the app. Given the choice between medium accuracy data and no data, we thought it would be better to get some data, so we added the button. Medium accuracy on iOS is actually pretty decent (section 7.2 of my thesis) and I am thinking of making it the default in the next version of emission. Regardless, the collection settings are completely configurable and you can use any values that you want for your instance.
I have never had any issues with android 😄 However, I also have not updated the platform to API 28, and I think that the store now requires all new apps to be minSDK = API 28. |
|
@stephhuerre which commit were you able to build from? We have been trying to build ios but no luck. Would be happy for any configuration that could bring us closer |
|
@shankari thanks for the tips. We are not using Apple sign so that shouldn't be a problem. And we will update to the Android API 28. I'll let you know how it all goes! @st-patrick we forked the last commit of this repository https://github.com/fabmob/e-mission-server-fabmob. To build the project in ios, I use the |
|
Just to ensure that we are on the same page and there are no surprises, upgrading to API 28 requires native code changes to the plugin. Android will then have the same "When in Use/Always" options as iOS. You need to change the plugin code to support the new calls. Are you planning to make plugin changes as well? If so, could you please contribute them to the platform? Then I don't have to hire anybody to make the changes 😄 If you are not comfortable making the native code changes, you may want to pledge support to the upgrade (#465). Ideally, @sunil07t can then get started on the changes over winter break so that we don't have to scramble to make changes at the last minute. |
|
@shankari |
|
@stephhuerre That is great! If you have any trouble, please file issues and I will be happy to help. Also, you might want to send out a draft PR as you are working on the changes. I can then give you quick feedback on obvious issues and hopefully save you some time when it comes to testing. |
shankari
added
the
usage
Hi @shankari,
We will be submitting our forked version of e-mission to the Stores soon.
Do you have any advice as we are setting up for Apple's review process?
I noticed you mentioned the medium accuracy tracking in the app description of TripAware. Was this as a result of an Apple reviewer's comment? We have disabled this functionality. I hope this will not play against us.
Are there any constraints that you know of that we should be aware of?
Any advice on Android as well?
Thanks
The text was updated successfully, but these errors were encountered: