We currently have an app on the app store that's been up for months now. Every release we've pushed has been approved just fine. The last vesion we tried to push we changed one thing and it was rejected and I am trying to figure out why. I know it has to do with augmented reality (which has also been in the app since the first release).
Here is what changed and our issue getting it approved.
The app was created with Unity3d. in previous releases you entered a login screen, logged in and were taken to a content selection screen in which the user selected which content they wanted to download and view. It then downloads the content. Everything here is fine. What changed was we noticed the analytics we were using for capturing how long the user was in the app was being reset because the permissions window that pops up when an AR scene is in use the first time calls OnApplicationPause. Our Analytics has an OnApplicationPause where if the user has the app paused (or just running in the background) it will end the current session and restart when the user brings back the app into focus. Because of this that popup messes with sessions. So we moved a check to determine if permissions were granted to the front of the app before they get to that content screen.
Because of this change Google has rejected the app pointing to the below policy:
Special restrictions:
If your app uses Augmented Reality, you must include a safety warning immediately upon launch of the AR section. The warning should contain the following:
An appropriate message about the importance of parental supervision.
A reminder to be aware of physical hazards in the real world (e.g., be aware of your surroundings).
So they are getting the same warning message about camera usage that they are then agreeing to its just not happening right when the AR camera is in use.
Can we just add our own message here? Does it have to be the permissions message in that scene only? I am not understanding if they are already aggreeing to those permssions why they would reject the app just because it isnt being displayed in that specific scene.
What is the best way to go about this?
Related
When opening an Unity app on the MSFT HoloLens it first creates a blank white box for the User to position and place via gestures. After the user has placed this white box, the application launches. The user can exit the app (but not necessarily close it) by performing the 'bloom' gesture. The app won't be running and the previously mentioned white box should re-appear (to denote this 'paused' state, as it were, between running and closed).
The issue is sometimes the app might have been exited and this white box doesn't appear. If the white box isn't present then the user can't close the application normally (by clicking the X in the top right). Likewise, if the app was exited and the user doesn't remember this when returning for their next session, they will naturally try to launch the application again. If the previous session was never actually closed it can cause issues with the newly opened session.
How do I restrict HoloLens from opening up a second instance of my Unity app, provided a session was previously opened and left either running or never closed?
Ideally if the app is already opened, when a user tries to open the app the HoloLens would refresh the previously existing instance and bring it to the users view or forcibly close the previous session before trying to open the new one (to avoid undesired behavior).
Is the best and most reliable way to handle this by enforcing a single instance of an Unity app on HoloLens? Or to detect if an instance is open and close that instance before trying to open the app again? Which, if either, is preferred or is it up to preference?
External resources I have found on this topic (a few of many):
How to determine if app is running on HoloLens - most relevant source of information I have found on the topic. Unfortunately it doesn't go into what to do with the affirmation that the app is open.
Unity Script Reference - WSA (Windows Store app) - again doesn't mention enforcing single running instance
Unity Script Reference - OnApplicationQuit - not sure if this is applicable to the situation but, there is a method Unity "sends to all game objects before the application is quit".
WIP:
private void App_Resuming(Object sender, Object e)
{
if (UnityEngine.VR.VRSettings.loadedDeviceName.Equals("HoloLens"))
{
UnityEngine.VR.VRDevice.SetTrackingSpaceType(UnityEngine.VR.TrackingSpaceType.Stationary);
UnityEngine.VR.InputTracking.Recenter();
UnityEngine.VR.VRDevice.SetTrackingSpaceType(UnityEngine.VR.TrackingSpaceType.RoomScale);
}
}
In the Initialize method (inside of 'App.cs')
public virtual void Initialize(CoreApplicationView applicationView)
Add
CoreApplication.Resuming += App_Resuming;
Can't test this at the moment as Hololens will connect to an network and spit out "No internet, connected" (tried both protected/unprotected networks). Device possibly needs an update, but we can't check for updates without a network connection.
For clarification, this is not a hololens specific question, where you need to look is in the windows 10 sdk, in windows 8 it was called tombstoning, its the act of moving away from an application without closing and being able to resume, Here is a link to an article about maintaining state in a windows 10 application, it's too long of a discussion and explanation to do it justice here.
https://visualstudiomagazine.com/articles/2015/09/01/its-universal.aspx
https://learn.microsoft.com/en-us/windows/uwp/launch-resume/app-lifecycle#app-execution-state
I have a CLLocationManager contained in a singleton and I have added around a dozen regions to monitor. I am successfully notified of boundary crossings when the app is in the foreground/background. However, when I force quit the app, the location icon disappears and I am not getting any callbacks.
As far as I can see, this is intended functionality as of iOS7. Here is a reply I found to a similar question, in this case involving significant location change: https://devforums.apple.com/message/882691#882691:
If a user swipes up in the app switcher then the OS will not launch the app unless explicitly told to do so by the user. So no, SLC will not be launching the app, nor will silent notifications. The only thing that will launch the app at that point is the user tapping the icon. The intention here is that the user has expressed their choice of not having that app running any more for any reason, so we honor that.
In this situation, there's really nothing that you can do. The next time the user launches the app you can let them know that some of the data may be missing, although you really cannot tell whether there's missing data or not (i.e. you might have been killed by the OS in the background and the user may not have moved thereby not triggering any SLC notifications). My suggestion would be to gather the data you can within the policies of the OS and if the user has manually killed the app then respect that wish and don't do anything.
By all means, feel free to file a bug report if this change in behavior winds up causing problems for you or (especially) confusion for your users.
My application uses the core location also after the application terminates with the method startMonitoringSignificantLocationChanges in CLLocationManager class.
My application launches with a location key in iOS 5 and 6 in the method:
- (BOOL) application:application didFinishLaunchingWithOptions:launchOptions;
in AppDelegate class and everything works well.
But in iOS-7 betas the application doesn't launch with a location key after a significant location change.
Has anybody encountered this problem?
I tried it on a simulator and in the device.
Thanks for the help.
I have the same problem in my app, when the app was terminated by user from app switcher.
But it does launch with location key if it was terminated by OS for low memory or other reason.
It is the expected result from iOS7 unfortunately. An official apple response I got from one of their evangelists:
If a user swipes up in the app switcher then the OS will not launch
the app unless explicitly told to do so by the user. So no, SLC will
not be launching the app, nor will silent notifications. The only
thing that will launch the app at that point is the user tapping the
icon. The intention here is that the user has expressed their choice
of not having that app running any more for any reason, so we honor
that. In this situation, there's really nothing that you can do. The
next time the user launches the app you can let them know that some of
the data may be missing, although you really cannot tell whether
there's missing data or not (i.e. you might have been killed by the OS
in the background and the user may not have moved thereby not
triggering any SLC notifications). My suggestion would be to gather
the data you can within the policies of the OS and if the user has
manually killed the app then respect that wish and don't do anything.
By all means, feel free to file a bug report if this change in
behavior winds up causing problems for you or (especially) confusion
for your users.
Attach link to Apple DEV forums:
https://devforums.apple.com/message/882691#882691
Until now asper my knowledge it was not possible to restrict the app from exiting. User could press the home button and app will exit. Then came multitasking and when we press home button app would go in background, but on long press user can still close the app.
I am working on developing anti-theft kind of application and needed to lock the phone programatically, but seems that it is not possible.
Also another problem was if user exits app then there is no way it will get notifications from the web. After some research I found the we can restrict the application from being exited using GUIDED ACCESS facility provided by iPhone6.
But all the links that I found states the procedure to do it from settings menu of iPhone.
I wanted to know if there is any way to do it programmatically or at least display relevent iphone settings screen directly.
It is not possible to restrict your app from exiting or allowing it to lock the iPhone programatically.
This is FAR beyond the scope and bounds of security for your app to infect the system this way.
As for Guided Access it is a feature provided in iOS6 allowing parents to use their device with their kids and prevent accidental app exits or unintentional taps outside a certain bounds. It also has availability in a kiosk mode for small businesses using iPads as public information access points that want the iPad locked to an app or webpage. It is not a public API allowing your app to turn such blocks on. This again is for the security of the device.
I am fairly new to iphone app development. I am creating an app that has multiple views. Initially it starts with a view for authentication and then load views according to user interaction. When I build and run the app - the first time it shows the "Default.png" screen and then shows the first view where I do my authentication process (typing in userid,password and do a web service) and then after the credentials are verified it takes me to the next view. When I close the app at this state in the simulator and reopen it again, I am seeing the same state in which I closed my app. But here is what I want. When I relaunch the app I should be able to show the "DEfault.png" and screen and then show my initial authentication view. Can you please help me out on this ? Thanks
It sounds like the problem you are trying to solve is that your authenticated session may time out while the app is suspended and you need to log in again.
Although the proposed solution (setting UIApplicationExistsOnSuspend to true) would work I think you should consider a different approach.
Apple recommends that you do everything you can to make it look like the phone supports multitasking. That is why, by default, your app will suspend and resume instead of exit and relaunch. In your case, though, you may need to re-login to resume the session. I offer you a couple of alternate solutions:
Cache the credentials (ie username and password) and silently use them to resume the session when needed. If the back-end supports this.
Detect when the session has become stale and bring in a view to inform the user that the session has expired and ask them to log in again. This would also address the issue if the user keeps the app active past the timeout of the session.
Both of these approaches should improve perceived app performance and integrate better into the Apple usability guidelines.
That's because iOS 4 apps are supposed to support multitasking. You can change the app so it doesn't: In Info.plist, set UIApplicationExitsOnSuspend to true (i.e. <key> UIApplicationExitsOnSuspend</key><true/>) — make sure it's a boolean and not a string. Note that this will probably make startup slower, since the app has to be launched again.
The other way is to handle applicationDidEnterBackground: in your app delegate and do two things:
Reset your view hierarchy (you can do this on next launch, but doing it earlier might help to free more memory)
Show "Default.png" in a full-screen view — iOS takes a screenshot of your app after it's hidden which it uses to animate the app back in.