Search Your Question

Showing posts with label App Level. Show all posts
Showing posts with label App Level. Show all posts

Explain application states in iOS

Ans : 

There are 5 application states :

  1. Not Running
  2. Inactive
  3. Active
  4. Background
  5. Suspended.
iOS Application states
Application States


iOS Application Lifecycle : 

When an iOS app is launched the first thing called is

Initialise :

application: willFinishLaunchingWithOptions:-> Bool.
This method is intended for initial application setup. Storyboards have already been loaded at this point but state restoration hasn’t occurred yet.

Launch :

application: didFinishLaunchingWithOptions: -> Bool is called next. This callback method is called when the application has finished launching and restored state and can do final initialisation such as creating UI.

applicationWillEnterForeground: is called after application: didFinishLaunchingWithOptions: or if your app becomes active again after receiving a phone call or other system interruption.

applicationDidBecomeActive: is called after applicationWillEnterForeground: to finish up the transition to the foreground.

Termination :

applicationWillResignActive: is called when the app is about to become inactive (for example, when the phone receives a call or the user hits the Home button).

applicationDidEnterBackground: is called when your app enters a background state after becoming inactive. You have approximately five seconds to run any tasks you need to back things up in case the app gets terminated later or right after that.

applicationWillTerminate: is called when your app is about to be purged from memory. Call any final cleanups here.


Both application: willFinishLaunchingWithOptions: and application: didFinishLaunchingWithOptions: can potentially be launched with options identifying that the app was called to handle a push notification or url or something else. You need to return true if your app can handle the given activity or url.

Above all methods are defined in UIApplicationDelegate and AppDelegate.swift has to implement these methods.

If you have any comment, question, or recommendation, feel free to post them in the comment section below!

Can you search your app content In spotlight (search bar)?

Ans : 


Using spotlight search, here we can find loan no 14356 in our application and redirect to view details page of this loan number.

Apple offers us many iOS features that can boost our apps visibility even when the user is not using it. For example, features like Spotlight, Today Widget, iMessage, Push Notifications, Siri and so on...

Spotlight is a super-powerful search feature in iOS that searches through the contents of your installed apps that support it.

If we want our app content to appear in Spotlight, we need to use the CoreSpotlight framework. For creating searchable content we will need to be familiar with:

  • CSSearchableItemAttributeSet - specifies the properties that you want to appear in Spotlight (i.e. title, contentDescription, thumbnail). 
  • CSSearchableItem - this class represents the search item. We can assign a unique identifier for referring the object, a domain to manage the items in groups and attributeSet where we pass the CSSearchableItemAttributeSet that we have created for this object. 
  • CSSearchableIndex - a class that is responsible for indexing the content on Spotlight. It requires an array of CSSearchableItem.
Let's understand through some coding :

We have array of favourite books : 

var favorites = [Int]()   ->   This array contains int id of favourite book.

To enable searching content, we have to add our favourite list in spotlight content like following :

First import ,
import CoreSpotlight 
import MobileCoreServices

When new item added to favourite, it should be also added using following custom function :


func index(item: Int) {
    let book = books[item]

    let attributeSet = CSSearchableItemAttributeSet(itemContentType: kUTTypeText as String)
    attributeSet.title = book[0]
    attributeSet.contentDescription = book[1]

    let item = CSSearchableItem(uniqueIdentifier: "\(item)", domainIdentifier: "com.iosiqabooks", attributeSet: attributeSet)
    CSSearchableIndex.default().indexSearchableItems([item]) { error in
        if let error = error {
            print("Indexing error: \(error.localizedDescription)")
        } else {
            print("Search item successfully indexed!")
        }
    }
}

Understanding above code :

Let's create CSSearchableItemAttributeSet object. This attribute set can store lots of information for search, including a title, description and image, as well as use-specific information such as dates (for events), camera focal length and flash setting (for photos), latitude and longitude (for places), and much more.

Regardless of what you choose, you wrap up the attribute set inside a CSSearchableItem object, which contains a unique identifier and a domain identifier. The former must identify the item absolutely uniquely inside your app, but the latter is a way to group items together. Grouping items is how you get to say "delete all indexed items from group X" if you choose to, but in our case we'll just use "com.iosiqaswift" because we don't need grouping. As for the unique identifier, we can use the project number.

To index an item, you need to call indexSearchableItems() on the default searchable index of CSSearchableIndex, passing in an array of CSSearchableItem objects. This method runs asynchronously, so we're going to use a trailing closure to be told whether the indexing was successful or not.

By default, search item expiry of 1 month. After 1 month, it is deleted from spotlight. We can manually set expiration date like :

item.expirationDate = Date.distantFuture : It will never expire.

If we want to remove content from spotlight or to disable search item for spotlight,

func deindex(item: Int) {
    CSSearchableIndex.default().deleteSearchableItems(withIdentifiers: ["\(item)"]) { error in
        if let error = error {
            print("Deindexing error: \(error.localizedDescription)")
        } else {
            print("Search item successfully removed!")
        }
    }
}

--------

We can now code for tapping on search result interaction in app delegate :

import CoreSpotlight in AppDelegate.swift.

We have to add following AppDelegate method :

func application(_ application: UIApplication, continue userActivity: NSUserActivity, restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void) -> Bool {
    if userActivity.activityType == CSSearchableItemActionType {
        if let uniqueIdentifier = userActivity.userInfo?[CSSearchableItemActivityIdentifier] as? String {
            if let navigationController = window?.rootViewController as? UINavigationController {
                if let viewController = navigationController.topViewController as? ViewController {
                    viewController.readBook(Int(uniqueIdentifier)!)
                }
            }
        }
    }

    return true
}

Credit : HackingWithSwift




Differences between internal testers and external testers in test-flight?

Ans : 

Both internal and external testers will install your app from the TestFlight app. Once invited, they will be sent an email asking them to install the TestFlight app. Once they have done so, they'll be able to install your beta app...
Internal Testers: Think of these users as employees who receive instant updates to your app without approval/review
  • Must be added manually via iTC
  • 25 Max allowed
  • Once your app is uploaded it's available immediately for internal testers (before it has been reviewed)
  • All internal testers must be added as a user in your iTC "Users and Roles" settings, which gives them certain permissions (review other answers and the docs for this). You wouldn't want to give just anyone permissions here.
  • Do not have a 60-day time limit
External Testers
  • Will only be able to use your uploaded build for up to 60 days. If you add additional builds, they can update, and the 60 days starts over again.
  • Will be able to test your app after
    1. You have submitted it for review
    2. It gets approved in TestFlight review and
    3. You set it to be available for testing. The review process us usually instant for new builds with the same version number. If you add a new version number, the review process can take up to 48hrs as of 10/2016.
  • Up to 2000 email addresses can be added. Each email address will allow a user to install the app on multiple devices. The email addresses do not need to match their Apple IDs.
  • They receive an invite to install your app once your first build is available for testing. If you add a new user after making a build available for testing, they'll immediately receive an invite. All users will receive notifications to install newer versions of the app if you upload additional builds.
  • Will be disallowed from using your app after you have pushed it to the official app store (which promptly ends the beta) or 60 days have passed since you started the beta, whichever comes first. If you end the beta without launching in the app store, and they try to open it, it will crash. Yay, Apple UX! If you do push a version to the app store with the same bundleName, version, and bundleID (build number doesn't matter), then your beta testers will automatically receive the app-store version of the app when it goes live.

What are certificates and provisioning profile for uploading app to app store?

Ans : 

Certificates - This is a cryptographic certificate granted to you by Apple.  It works just like SSL where you get a certificate signed by an authority.  Apple signs the private key that you use to sign different pieces of your application.  Different certificates create different types of trust.  Some allow you to sign and submit your application for the App Store, while others allow your application's web server to send push notifications to users via APNS.  In the latter case, for instance, Apple uses this certificate to trust the web server sending the push notification.  Otherwise, it would be easy for an attacker to spoof a valid push notification and spam users.  The most common certificate you would create signs the key you use to deploy your application to a device or submit it to the App Store.

When you create a certificate through Apple's developer portal, you have to create your key pair and send a "Certificate Signing Request," which at first is likely pretty confusing to developers just trying to see their application run on a device.
If you visit the developer portal, you'll find you can create certificates for Development or Distribution.  These certificates are rooted to different authorities, so that the two worlds are never confused (though all iOS devices trust both in a seemingly equal fashion).
Provisioning Profiles - Probably the most confusing component in the system, a provisioning profile indicates the devices for which an application is correctly signed.  If you visit the developer portal, you'll notice you can create two types (again called Development and Distribution).  Provisioning profiles say "applications with this Identifier signed with this Certificate's private key are okay to run on these devices."  Now that you know a provisioning profile is tied to a certificate, you can see why you have to decide whether to create a Development or Distribution profile.  Development profiles are limited to 100 devices.  Distribution profiles can either be Ad-Hoc or App Store distribution profiles.  I am not sure whether Ad Hoc profiles have device limits.
You might ask, then, why not always use a Distribution profile?  It can deploy to an unlimited number of devices, and is still attached to a certificate owned by the developer.  Another piece of Apple's security puzzle are Entitlements.  In an iOS application's bundle, you'll find Entitlements.plist, which is a list of capabilities that an application wants.  When signing your application using a certificate intended for distribution, Xcode (really the signing utility) will not allow an entitlement with get-task-allow set to YES.  This is because get-task-allow is what allows a debugger to connect to a process, and Apple doesn't want that happening on apps meant for distribution.


Short Ans : 

1. A Certificate authenticates you as an entity. It can represent you as an individual, or your company.
2. The Identifier is a unique ID for your mobile app.
3. A provisioning profile associates your certificate with the App ID. It is the link between #1 and #2 above.



What are the app id and bundle identifier?

Ans : 
Bundle ID : 
A bundle ID or bundle identifier uniquely identifies an application in Apple's ecosystem. This means that no two applications can have the same bundle identifier. To avoid conflicts, Apple encourages developers to use reverse domain name notation for choosing an application's bundle identifier.
i.e com.iosiqa.newapp or com.iosiqa.app.new

App ID : App ID consists of Team ID + Bundle ID. Team ID is provided by apple to one team in developer account.
i.e ABC12345.com.iosiqa.newapp

What is use of APP ID? 
Whenever you want to enable a capability or application service for your application, you enable that capability for the App ID your application is linked to. This used to be tedious, requiring a visit to Apple's developer website. Xcode has evolved quite a bit over the years and it takes care of the details most of the time.

Application States

Ans : 

Before iOS 4.0 there were 3 states. Not running, inactive and active.

  1. Non-running - The app is not running.
  2. Inactive - The app is running in the foreground, but not receiving events. An iOS app can be placed into an inactive state, for example, when a call or SMS message is received.
  3. Active - The app is running in the foreground, and receiving events.
  4. Background - The app is running in the background, and executing code.
  5. Suspended - The app is in the background, but no code is being executed.
For maintaining above states, there are following app delegate methods:


application:willFinishLaunchingWithOptions (First method)
Method called when the launch process is initiated. This is the first opportunity to execute any code within the app.

application:didFinishLaunchingWithOptions
Method called when the launch process is nearly complete. Since this method is called is before any of the app's windows are displayed, it is the last opportunity to prepare the interface and make any final adjustments.

applicationDidBecomeActive
Once the application has become active, the application delegate will receive a callback notification message via the method applicationDidBecomeActive.

This method is also called each time the app returns to an active state from a previous switch to inactive from a resulting phone call or SMS.

applicationWillResignActive
 Each time a temporary event, such as a phone call, happens this method gets called. It is also important to note that "quitting" an iOS app does not terminate the processes, but rather moves the app to the background.

applicationDidEnterBackground
This method is called when an iOS app is running, but no longer in the foreground. In other words, the user interface is not currently being displayed. According to Apple's UIApplicationDelegate Protocol Reference, the app has approximately five seconds to perform tasks and return. If the method does not return within five seconds, the application is terminated.

applicationWillEnterForeground
This method is called as an app is preparing to move from the background to the foreground. The app, however, is not moved into an active state without the applicationDidBecomeActive method being called. This method gives a developer the opportunity to re-establish the settings of the previous running state before the app becomes active.

applicationWillTerminate
This method notifies your application delegate when a termination event has been triggered. Hitting the home button no longer quits the application. Force quitting the iOS app, or shutting down the device triggers the applicationWillTerminate method. This is the opportunity to save the application configuration, settings, and user preferences.



Which delegate method called when I click on app icon, while app is in background?

Ans :

Following methods called :

If not background : 

1. DidFInishLaunchingWithOptions

If background : 

1. application Willenterforeground
2. applicationDidBecomeActive

Tricky note : Here didFinishLaunchingWithOptions not called.

Q. Which app delegate methid called when application is to be killed?
A. applicationWillTerminate:



What is app thining?

Ans : App thinning automatically detects the user’s device type (i.e. model name) and only downloads relevant content for the specific device. In other words, if you’re using an iPad Mini 1 (which does not have a retina display but rather a 1x resolution), then only your 1x files (more on this in a moment) will be downloaded.  The assets for more powerful and sharper iPads (such as the iPad Mini 3 or 4) will not be available for download).  Because the user needs only download the content that targets his/her specific device, this speeds up the download process and saves space on the device.

There are three aspects of app thining.

1. App Slicing : Slicing is the process of creating and delivering variants of the app bundle for different target devices. App Slicing delivers only relevant assets to each device (depending on screen resolution, architecture, etc.)  In fact, app slicing handles the majority of the app thinning process.
When you’re ready to submit the app, you upload the .IPA or .App file to iTunes Connect, as you typically would (but must use Xcode 7 as it contains the iOS 9 SDK with support for app thinning). The App Store then slices the app, creating specific variants that are distributed to each device depending on its capabilities.

2. On Demand Resources : On demand resources are files that can be downloaded after the app’s first installation.  For example, specific levels of a game (and these levels’ associated content) could be downloaded only when the player has unlocked them.  Further, earlier levels that the player has not engaged with after a certain set time can be removed to save storage on the device.
Enabling on demand resources involves changing the “Enable On Demand Resources” boolean to “Yes” in Xcode settings (under Build Settings).

3.  Bitcode : Bitcode makes apps as fast and efficient as possible on whatever device they’re running.  Bitcode automatically compiles the app for the most recent compiler and optimizes it for specific architectures. Can be turned on by the project settings under Build Settings and selecting bitcode to YES.

App thining process can be test by TestFlight software and install in various device. Size may be vary.