Hope you're well. Two quick guidance questions from the community. And I really value your advice. We're a fintech company and hoping to do an external tester effort of a few thousand folks in testflight. That said, had two questions:
I recall it's not possible to test actual transactions in testflight (commerce, banking, otherwise). Is that the case or am I mis-remembering?
Irrespective of the above, one of the concerns is the transition from testflight to live app store. If I recall correctly, there's no way to port X number of people in your external tester effort to the live app and save their info, correct? You basically have to start fresh with those folks (i.e. have them go to the app store, download the released/consumer version, then set up all new accounts where it'd be hard to port to their new accounts their testflight account data)?
Warmest thanks for the feedback! Hope the appreciation comes across.
Evan
Related
I created an application that simply spins a picture of my goose on screen. That's it. Nothing else.
Could that be deployed to the app stores?
Context:
I'm a mobile app engineer for a few different companies (finTech, gigEconomy, social...) and all of our applications have very specific use cases for the end user.
I'm also an artist in my own time, and have built a few different apps that help people make art.
For each of these, the data gathered by the apps must be well documented and explained to the end user to be accepted by the App Store along with the purpose of that collection.
That's got me thinking, would the Apple App Store accept an app that does not collect any user data at all, but also has no true "purpose"? (Google Play Store too, though I expect their review process is so easy you can get just about anything up there anyways...)
I haven't found any relevant answers to this question online and might test it just for fun, but would love some insight by other curious developers if they have tried uploading apps just for fun
You might find the following section from the official App Store Review Guidelines useful:
4.2 Minimum Functionality
Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or “app-like,” it doesn’t belong on the App Store. If your App doesn’t provide some sort of lasting entertainment value or adequate utility, it may not be accepted.
Does this include a purpose or does this mean that an app like you have suggested in your scenario gets rejected? Absolutely not.
After a quick google search, I have found the IsItMyBirthday app which lets you pick a date and it tells you if that date is today. Is this useful or unique? We could just look up the date in the calendar on the phone itself.
However, this could be considered a 'joke' and a joke has a purpose and might be considered as unique. An app that does nothing, could be considered a joke as well. It has a purpose and Apple might agree or disagree.
In my experience it can be very random on why an app gets rejected or accepted. For example one of our apps got rejected in version X for reason Y. We released a new version without changing Y and it was accepted.
My team will make an application for business solution. We need a way for deployment because we have customers more than 5, but we want to use just one build for our app. And we have a problem, because we don't want to publish our app to appstore or playstore, we want to serve directly our customer's clients. And there is a handicap, because our customer's networks are restricted. We have searched for a lot of ways, but none of us can take us to the conclusion.
Can you guide us if anyone live in a similar situation?
Thank you,
Mert
Try this, use just one build for your app, upload and share it.
https://www.diawi.com/
I have an app in the iTunes Store and sales have slowed so want to convert it to a free app from a paid app. The new app will contain an option to buy, using In App Purchase. I was considering using a flag / pre processor macro to then allow full features for those that buy using the IAP, and limit features for those who have not.
The problem will be if I add this new pre processor macro to the new update, those who have previously paid for the app will not be able to use full features, as they would not have used the IAP to "unlock" the full app.
Does anyone have any suggestions to overcome this problem.
I have a few ideas, but in my mind they are not fool proof.
Thanks for assistance.
Pondering exactly the same issue here. The only thing i found workable (under most use cases) is to look-up gamestate information at when the new_free_iAP version starts.
If there is no iAP state, AND if games exist, AND the playtime counter > 0, i will make the assumption that the user bought this and will preseed his/her iAP configuration information to indicate that this was iPurchased. The only users left out would be buyers who NEVER started the app.
Not fool proof, but better than none. Ugly state to manage, nasty testing for this. And of course, this is a variable geometry solution : if I did not have reliable persisted state in the current version, i would not know where to start.
I was wondering if anyone has any experience of submitting location-specific apps to the Apple App store.
What I mean by location-specific is an app that only works when you are at a particular location. For example, a GPS tour of a historical battleground might have content that is triggered at particular lat/long coordinates when the user is at the actual physical location.
So my question is: In order to make the app be likely to be accepted on the app store do I..
(1) Not worry about it as there's evidence that the Apple Reviewers have some way of simulating the GPS. I can then supply lat/long coords to the reviewers so they can experience some of the content.
or (I suspect more likely)
(2) I Need to make it work anywhere in order for the reviewer to see at least some of the content (e.g. have a menu or map interface that allows direct access). This could be a 'secret' option explained in the review notes accessed via a special key combination or something.
Has anyone else run into a situation like this?
Regards,
Ben
Edit: Thanks for the responses. My app has now been accepted by Apple. Interestingly I didn't need to make the app work anywhere or add any new methods of using the app at all, they simply asked me for a video of the app in action. I made a YouTube video of the app (unlisted of course) and sent it to the reviewers.. and now it's accepted! I was very surprised that this is how it worked out!
I asked this same question (and answered it myself) a while back. I basically added a "Drop Pin" feature so the testers (and users) could pretend to be somewhere else.
I submitted an app recently that "works anywhere" (and uses GPS) but "works best" in New England when looking for data (on our server) that is near your current location. The app also supports entering a city & state or zip code to perform searches. So, in the submission, you can tell the reviewers how to test it, and we explained the nature of the app and how to test the functionality by using specific New England locations. The app was approved, for what it's worth.
Basically, when you submit an app, there is an opportunity to give the reviewers guidance. So definitely tell them what they need to know to make your app work for them, wherever they might be in the world! :-)
I have a little experience with bug tracking systems such as FogBugz where help tickets are issues are (or can be) bugs, and I have some experience using a bug tracking system internally completely separate from a help center system.
My question is, in a company with an existing (home-grown) help center system where replacing it is not an option, how should a bug tracking system (probably Mantis) be integrated into the process?
Right now help tickets get put in for issues, questions, etc and they get assigned to the appropriate person (PC Tech, Help Desk staff, or if it's an application issue they can't solve in the help desk it gets assigned to a developer). A user can put a request for small modifications or fixes to an application in a help ticket and the developer it gets assigned to will make the change at some point, apply their time to that ticket, and then close the ticket when it goes to production.
We don't currently have a bug tracking system, so I'm looking into the best way to integrate one. Should we just take the help tickets and put it into the bug tracking system if it's a bug (or issue or feature request) and then close the ticket if it's not an emergency fix? We probably don't want to expose the bug tracking system to anyone else as they wouldn't know what to put in the help center system and what to put in the bug tracker... right?
Any thoughts? Suggestions? Tips? Advice? To-dos? Not to-dos? etc...
Have a promote to bug button on the help desk system, that publish the ticket on the bug tracker, with the appropiate reference info.
Is this for a production system with end users reporting bugs, or for issue resolution during QA?
If it is the former, some live person should triage the help desk tickets and only log as a bug what really is one.
If it is the latter, you should not integrate at all.
Well, it's a tradeoff.
We use separate systems for help desk tickets and for bugs.
Pros:
Workflows & requirements will probably different between devs and help desk, you can choose a system for each that fits requirements (e.g. fields that are only relevant for dev or for help desk, different kinds of email integration).
Clear responsibilities: Help desk handles tickets, devs handle Bugs.
Cons:
Integration will not be quite seamless (you need either automatic integration, which does not always exist, or manual back-forth links, which people may forget).
So far, we're quite happy with two products. It is occasionally annoying to have to paste links or close a ticket and a bug, but usually tickets and bugs are handled by different people anyway, so it's not a big deal.
One product might also work well, if you can find one which fits everyone's workflow.
In the raiseaticket help-desk system, we create a separate workflow for Prod, Dev and Bugs. The ticket is assigned to relevant group based on the nature of the issue. These tickets are not exposed to any other group. So, we can do a workaround in our help-desk portal system for the bug tracking.
For anyone in 2022 (and beyond) looking to integrate a help desk system and bug tracker, DoneDone does this well.
We use a DoneDone mailbox for general customer support (both via our support email address and the contact form on our website). It lets you have private discussion on emails, along with allowing you to assign, prioritize, tag, and create/change statuses on them (e.g. "Open", "In Progress", etc.)
We use DoneDone projects to manage internal bugs/issues/tasks.
DoneDone lets you connect support emails (the helpdesk part) to internal tasks (the bug tracking part) as well. So, if your company has distinct support and client-facing people while also having internal devs and you want to separate their work, you can create any number of subtasks from an incoming conversation.
Even if your company isn't that stratified, it's nice to be able to create bugs with their own workflows separate from a helpdesk ticket (which has its own workflow).
More info at https://www.donedone.com