I am building a native iPhone application wherein this application will act as a standalone app on one device and act as a library on other device. Can you please guide me how should I design the app. Should the same method "applicationDidFinishedLaunching" be called in both the cases and just in the basis of some parameters I will be distinguishing from where the call was made. This is because, in both the cases, I have some different screen flows.
Library code has to be compiled into the running app to be used. No other app can access your code, as all apps are sandboxed and prohibited from accessing each other's directories, and thus any code contained in such. If someone taps on another icon, it will be as if your library code does not exist to that app.
Another app can start your app by using a registered launch URL, but that will just result in your app being brought to the foreground. The other app will be put into the background or terminated.
Related
I coded my app with several ViewControllers including an initial WelcomeVC. My app works well and I have no delay when launching it. I have seen that LaunchScreen.storyboard is used for first screen when app is launched but I don't need it in my app. I want to use it and submit it this way to the App Store without LaunchScreen. Do you know if this is possible?
Nevertheless I tried to add a simple LaunchScreen but I see no utility as on my Iphone when the App starts it goes so quick that I don't see the LaunchScreen.
Can I post an app without LaunchScreen?
Can I post an app without LaunchScreen?
No. Well, you can post it, but it will be rejected.
The launch screen does more than just provide an interim screen during launch. It also acts as a signal so that the device knows your app can adapt to it. Therefore Apple now requires (or soon will require) that an app submitted to the app store have a launch screen.
I wrote an app that implements FinderSync extension.
Everything works fine, I can "communicate" by sending notifications through DistributedNotificationCenter from extension to main app. But obviously it works if the main app is running only.
Is there any mechanism to open terminated app and pass parameters?
UPDATE:
The idea is to implement simple image processing app. I want to run the main app (containing execution code and GUI) from Finder-Sync extension.
To be more specific I implemented func menu(for menu: FIMenuKind) -> NSMenu? of FIFinderSyncProtocol and I want to run/open main app when user right-clicks the menu item and selects operation I added into menu.
As I guess that my comment is at least somewhat valid, I'll put it in the answer.
Extensions allow launching of the main app by using the URL that app handles.
Communication with URL may not be enough, but you can have the app group where extension could write the data to disk and be readable by the main app or use your current way of communication with some adaptations to this method.
You can use SMLoginItemSetEnabled to launch background "helper" application.
https://developer.apple.com/documentation/servicemanagement/1501557-smloginitemsetenabled
This helper app can be launched in the background by a sandboxed app with few restrictions, and kept open when then main app closes. Your FinderSync extension can continue to communicate with the helper app even if the main app is closed.
Basically, I need to call a service to perform a simple get operation in my iOS app that I have built using Xamarin. The problem is I need to do this when the app fires up.
I have an in-house app that is being distributed to employees, and I need to call a service when the app starts to check for a newer version. How would I do this?
Create a Splash screen that is having the same layout as the LaunchScreen. Set the Splash screen as the first screen to show. Then you can call to your service from the Splash screen during ViewDidLoad.
If you plan to show dialog to force user to update app, you might have risk that Apple reject your app. Apple rejected app because I am forcing users to update their app version
You can just put it in FinishedLaunching delegate in AppDelegate.cs file where is used to setup your app. Then your new version checking service will start when user launches your app.
As you are using an in-house app which doesn't need to be reviewed by Apple, so there's no rejection risk on forcing update which #lowleetak mentioned.
Is there any provision in iOS wherein the referral parameters used to start the iTunes application are passed on to the application on its first run?
For example in Android, if I use a link such as http://market.an......com.company.pany&referrer=heythere to download an app on Android and actually install the app, the Market app passes the "referrer" parameter and its value to the app on its first run, which the app can use to any extent.
Is there a similar provision in iOS?
We also struggled with this when we built our last mobile app, Kindred Photobooks. The best way we found is to basically bundle that information in the link and use fingerprinting to make that data available after install, which is working really well.
You can try to build fingerprinting in in house. Basically the steps would be the following:
1. When a link gets created, appending parameters to the link, or create a link reference in some backend database if you want shortened links
2. When a user clicks on that link, collect a fingerprint of their device from everything you can read in the browser (for example: IP, OS, screen size, etc) and redirect that user to the app store.
3. When the app opens, create a similar fingerprint from the same parameters collected in app, and match it up in your database to the outstanding fingerprint.
4. If there is a match, you can return those link parameters to the app through install.
Alternatively, if you don't want to build all that infrastructure and handle the many edge cases, we bundled it up into a free service called Branch. Check it out at http://branch.io
No, there is no such thing on iOS. But you can and should file a feature request at bugreport.apple.com, if you really need this feature.
As of iOS6, if someone installs your applications via a smart banner, you can pass a url to your app on startup. You do this by using the app-argument parameter:
A URL that provides context to your native app. If you include this, and the user has your app installed, she can jump from your website to the corresponding position in your iOS app. Typically, it is beneficial to retain navigational context because:
It should work on install:
When the app finishes downloading [after clicking install on an app banner], the View button changes to an Open button, and tapping the banner will open the app while preserving the user’s context from your website.
More here: http://developer.apple.com/library/ios/#documentation/AppleApplications/Reference/SafariWebContent/PromotingAppswithAppBanners/PromotingAppswithAppBanners.html
I think this will work (but the jury is still out: Does app-argument on Apple Smart Banner get passed to app on install? ), but testing this is tough: How to test Smart App Banner Urls on in Dev environment
No, AppStore doesn't pass any parameters to application - it just unzips ipa to application folder (container).
It seems like Info.plist file has an ability to declare different roles for the same application bundle through the UIRoleInfo key. SpringBoard can recognize these roles after installing an app and may display separate icons for each application role.
For instance, iPhone shows MobileSlideShow.app as 2 different programs: Photos and Camera.
Unfortunately, there is no official Apple documentation about the subject at the moment. Would anybody advise how to organize the same behavior in a custom app?
This feature is going to be used in the Enterprise product for ad hoc distribution.
This isn't a supported feature, so if you do this you might have a hard time getting your app through the approval process. I wouldn't recommend using it.
Have you tried it to see if it works? If it doesn't work, you could create a second app that does nothing but launch the first one, with a custom URL scheme. The first app can recognize when it is being launched with that URL. This is not ideal as you will see the second app launch & quit (though it should be really fast).