Search Your Question

Showing posts with label Difference. Show all posts
Showing posts with label Difference. Show all posts

Difference between assign and retain in iOS

In the context of memory management in programming, particularly in Objective-C (though less relevant in modern Swift), "assign" and "retain" are related to the property attributes used in the declaration of object properties.

  1. Assign:

    • In the context of Objective-C, the assign attribute is used for simple assignments and is often associated with primitive types or non-Objective-C objects.
    • When you declare a property with the assign attribute, you're saying that the property will just take the value assigned to it without affecting the reference counting of the object.

    • @property (assign) NSInteger someInteger;

    • For objects, assigning does not increase the retain count, so if the assigned object is deallocated elsewhere, you might end up with a dangling pointer.

  2. Retain:

    • The retain attribute, on the other hand, is used when you want to claim ownership of an object. It increases the retain count of the object, indicating that you want to keep a reference to it.
    @property (retain) NSString *name;

    • When using retain, it's your responsibility to release the object when you're done with it. This is crucial to avoid memory leaks.

    • [name release];

    • In modern Objective-C and Swift, Apple introduced Automatic Reference Counting (ARC), which essentially automates the reference counting process. In Swift, you generally use strong instead of retain, and the memory management is handled by the ARC.

In summary, the key difference is that assign is used for non-object types and doesn't affect the reference counting of objects, while retain (or strong in Swift) is used for objects, and it does increase the retain count, indicating ownership. With ARC in Swift, the need to manually specify assign or retain has diminished, as ARC takes care of many memory management tasks automatically.AI.

Difference between App Store Binary Rejection and Metadata rejection

When submitting an application to the App Store, developers may encounter two types of rejections: App Store Binary Rejection and Metadata Rejection. Understanding the difference between these rejections is essential for iOS developers using Xcode to maximize their chances of successfully getting their apps approved.

Difference between App Store Binary Rejection and Metadata rejection

App Store Binary Rejection refers to the rejection of the compiled binary code that forms the application. This rejection can stem from numerous reasons, such as memory leaks or violations of Apple's App Store Review Guidelines. Memory leaks occur when an app fails to release dynamically allocated memory, resulting in wasted memory resources and potential crashes. To mitigate memory leaks, developers must carefully use memory allocation and deallocation mechanisms provided by iOS and Xcode, such as ARC (Automatic Reference Counting) or manual memory management.

On the other hand, Metadata Rejection deals with issues related to the app's information and presentation on the App Store. It primarily focuses on the textual and visual components, including the app's name, description, screenshots, keywords, and other metadata. Common reasons for metadata rejection can include misleading app descriptions or inappropriate screenshots that do not accurately represent the actual app functionalities.

To avoid both types of rejections, it is imperative for developers to pay attention to detail during the development and submission process. After addressing potential memory leaks by employing proper memory management practices, developers must also ensure that the app's metadata accurately reflects its functionalities and adheres to Apple's guidelines. By debugging their code thoroughly using instruments provided by Xcode, developers can identify and resolve any memory leaks, while adhering to Apple's App Store Review Guidelines can prevent metadata rejection.

In conclusion, developers using Xcode to create iOS apps must be aware of the distinction between App Store Binary Rejection and Metadata Rejection. By addressing memory leaks, adhering to Apple's guidelines, and carefully preparing app metadata, developers can increase the chances of getting their apps approved on the App.AI.

Difference between Value type and Reference type

Value Types

value type instance is an independent instance and holds its data in its own memory allocation. There are a few different value types: Struct, Enum, Tupple.


Let’s experiment with struct and prove that they’re value types:

Add the following code to your playground:

// 1
struct Car {
    let brand: String
    var model: String

// 2
var golf = Car(brand: "Volkswagen", model: "Golf")
// 3
let polo = golf

// 4
golf.model = "Golf 2019"

// 5

In the code above, you will:

  • Create a Car struct with brand and model properties.
  • Create a new instance of Car named golf.
  • Create a copy of the golf instance, named polo.
  • Change the golf.model variable to Golf 2019
  • Print the 2 different instances. The first print statement prints Car(brand: "Volkswagen", model: "Golf 2019") in the Console. The second one prints Car(brand: "Volkswagen", model: "Golf"). Even if polo is a copy of golf, the instances remain independent with their own unique data copies.

With this simple playground, we’ve confirmed that structs are indeed value types.


To check that enums are value types, add this code to the playground:

// 1
enum Language {
    case italian
    case english

// 2
var italian = Language.italian
// 3
let english = italian

// 4
italian = .english

// 5

In the code above, you will:

  • Create a Language enum with italian and english cases.
  • Create a new instance of Language for the italian language.
  • Create a copy of the italian instance, named english.
  • Change the italian instance to english.
  • Print the two different instances. The first print statement prints english, and the second one prints italian. Even if english is a copy of italian, the instances remain independent.


The last value type that we'll explore is tuple. A tuple type is a comma-separated list of zero or more types, enclosed in parentheses. You can access its values using the dot (.) notation followed by the index of the value.

You can also name the elements in a tuple and use the names to access the different values.

Add the following code to the playground:

// 1
var ironMan = ("Tony", "Stark")
// 2
let parent = ironMan

// 3
ironMan.0 = "Alfred"

// 4

In the code above, you will:

  • Create an ironMan tuple with the strings Tony and Stark.
  • Create a copy of the ironMan instance, named parent.
  • Change the ironMan.0 index to Alfred.
  • Print the 2 different instances. The first print, prints ("Alfred", "Stark") and the second one, prints ("Tony", "Stark"). Again, the instances remain independent.

You can now be certain that structsenums, and tuples are value types

When to Use Value Types

Use value types when comparing instance data with == makes sense.
== checks if every property of the two instances is the same.
With value types you always get a unique, copied instance, and you can be sure that no other part of your app is changing the data under the hood. This is especially helpful in multi-threaded environments where a different thread could alter your data.

Use a value type when you want copies to have an independent state, and the data will be used in code across multiple threads.

In Swift, ArrayString, and Dictionary are all value types.

Reference Types

In Swift, reference type instances share a single copy of their data, so that every new instance will point to the same address in memory. A typical example is a classfunction, or closure.

To explore these, add a new function to your playground:

func address<T: AnyObject>(of object: T) -> Int {
    return unsafeBitCast(object, to: Int.self)

This function prints the address of an object, which will help you check whether you're referencing the same instance or not.


The first reference type that you'll look at is a class.

Add the following code to your playground:

// 1
class Dog: CustomStringConvertible {
    var age: Int
    var weight: Int

    // 2
    var description: String {
        return "Age \(age) - Weight \(weight)"

    // 3
    init(age: Int, weight: Int) {
        self.age = age
        self.weight = weight

// 4
let doberman = Dog(age: 1, weight: 70)
// 5
let chihuahua = doberman

// 6
doberman.age = 2
// 7
chihuahua.weight = 10

// 8

// 9
print(address(of: doberman))
print(address(of: chihuahua))

In the code above, you will:

  • Create a new class named Dog, that conforms to CustomStringConvertible to print the custom descriptions of the object.
  • Define the custom description of the object.
  • Create a new init function. This is needed because, unlike a struct, a class doesn't automatically create an initialization function based on the variables of the object.
  • Create a doberman instance of Dog.
  • Create a copy of doberman, named chihuahua.
  • Change the doberman.age t2.
  • Change the chihuahua.weight t10.
  • Print the description of the two different instances. The first print, prints Age 2 - Weight 10, and the second one prints the same; Age 2 - Weight 10. This is because you're actually referencing the same object.
  • Print the address of the two different instances. With these prints, you'll be sure that you're referencing the same address. You'll see that both print statements print the same value.

You can rest assured that a class is a reference type.

Functions and Closures

closure is used to refer to a function along with the variables from its scope that it encapsulates. Functions are essentially closures that store references to variables in their context.

Take a look at the code below:

let closure = { print("Test") }
func function() -> (){ print("Test") }


They both do the same thing.

You can find more info about closures in Swift's docs.

When to Use Reference Types

Use a reference type when comparing instance identity with ===makes sense. === checks if two objects share the same memory address.

They’re also useful when you want to create a shared, mutable state.

As a general rule, start by creating your instance as an enum, then move to a struct if you need more customization, and finally move to class when needed.

Difference between method and function

Methods belong to classes, structs, and enums, whereas functions do not.

Methods always belong to a data type, they have a concept of self that functions do not. This is a special value passed in by Swift, and it refers to whatever instance the method was called on.

Swift uses the same keyword, func, for both functions and methods.

Difference between Swift and Objective C




Swift is a general-purpose, high-level programming language that is highly concerned about safety, and performance.

Objective C is a general-purpose language that is considered a superset of C language it was designed with the aim of providing object-oriented capabilities.

It was developed by Chris Lattner with eventual collaboration with other programmers at Apple.

It was developed by Brad Cox and Tom Love at their company Stepstone.

It was influenced by Objective C, Rust, Ruby, and Python.

It was influenced by C and Smalltalk.

Swift first appeared on the year 2014.

Objective C first appeared on the year 1984.

Swift is a static type.

Objective C is dynamic type.

Swift is apache licensed open-source project.

Objective C is licensed under General Public License.

It only has classes.

It has both Structs and classes.

It was designed for building apps for iOS, Mac, Apple TV, and Apple Watch.

Objective C was designed to be Smalltalk messaging features.

Swift polymorphism does not exist directly.

Polymorphism in Objective C exists directly in compile time.

It uses true and false values.

It uses YES and NO values and also BOOl.

Swift has multiple types of templates than Objective C.

Objective C lacks templates than Swift.

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.