#appdeveloperbali

What’s the only thing worse than having a buggy app rejected by the App Store? Having it accepted. Once the one-star reviews start rolling in, it’s almost impossible to recover. This costs companies money and developers their jobs. iOS is now the second-largest mobile operating system in the world. It also has a very high adoption rate, with more than 85% of users on the latest version. As you might expect, highly engaged users have high expectations—if your app or update isn’t flawless, you’ll hear about it. With the demand for iOS developers continuing to skyrocket, many engineers have switched to mobile development (more than 1,000 new apps are submitted to Apple every day). But true iOS expertise extends far beyond basic coding. Below are 10 common mistakes that iOS developers fall prey to, and how you can avoid them.

85% of iOS users use the latest OS version. That means they expect your app or update to be flawless.

Common Mistake #1: Not Understanding Asynchronous Processes

A very common type of mistake among new programmers is handling asynchronous code improperly. Let’s consider a typical scenario: User opens a screen with the table view, some data is fetched from the server and displayed in a table view. We can write it more formally: @property (nonatomic, strong) NSArray *dataFromServer; - (void)viewDidLoad { __weak __typeof(self) weakSelf = self; latestDataWithCompletionBlock:^(NSArray *newData, NSError *error){ weakSelf.dataFromServer = newData; // 1 }]; ; // 2 } // and other data source delegate methods - (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section { return self.dataFromServer.count; } At first glance, everything looks right: We fetch data from the server and then update the UI. However, the problem is fetching data is an asynchronous process, and won’t return new data immediately, which means reloadData will be called before receiving the new data. To fix this mistake, we should move line #2 right after line #1 inside the block. @property (nonatomic, strong) NSArray *dataFromServer; - (void)viewDidLoad { __weak __typeof(self) weakSelf = self; latestDataWithCompletionBlock:^(NSArray *newData, NSError *error){ weakSelf.dataFromServer = newData; // 1 ; // 2 }]; } // and other data source delegate methods - (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section { return self.dataFromServer.count; } However, there may be situations where this code still does not behave as expected, which brings us to …

Common Mistake #2: Running UI-Related Code on a Thread Other than the Main Queue

Let’s imagine we used corrected code example from the previous common mistake, but our table view is still not updated with the new data even after the asynchronous process has successfully completed. What might be wrong with such simple code? To understand it, we can set a breakpoint inside the block and find out on which queue this block is called. There is a high chance the described behavior is happening because our call is not in the main queue, where all UI-related code should be performed. Most popular libraries—such as Alamofire, AFNetworking, and Haneke—are designed to call completionBlockon the main queue after performing an asynchronous task. However, you can’t always rely on this and it is easy to forget to dispatch your code to the right queue. To make sure all your UI-related code is on the main queue, don’t forget to dispatch it to that queue: dispatch_async(dispatch_get_main_queue(), ^{ ; });

Common Mistake #3: Misunderstanding Concurrency & Multithreading

Concurrency could be compared to a really sharp knife: You can easily cut yourself if you’re not careful or experienced enough, but it’s extremely useful and efficient once you know how to use it properly and safely. You can try to avoid using concurrency, but no matter what kind of apps you’re building, there is really high chance you can’t do without it. Concurrency can have significant benefits for your application. Notably: Almost every application has calls to web services (for example, to perform some heavy calculations or read data from a database). If these tasks are performed on the main queue, the application will freeze for some time, making it non-responsive. Moreover, if this takes too long, iOS will shut down the app completely. Moving these tasks to another queue allows the user to continue use the application while the operation is being performed without the app appearing to freeze. Modern iOS devices have more than one core, so why should the user wait for tasks to finish sequentially when they can be performed in parallel? But the advantages of concurrency don’t come without complexity and the potential for introducing gnarly bugs, such as race conditions that are really hard to reproduce. Let’s consider some real-world examples (note that some code is omitted for simplicity). Case 1 final class SpinLock { private var lock = OS_SPINLOCK_INIT func withLock(@noescape body: () -> Return) -> Return { OSSpinLockLock(&lock) defer { OSSpinLockUnlock(&lock) } return body() } } class ThreadSafeVar { private let lock: ReadWriteLock private var _value: Value var value: Value { get { return lock.withReadLock { return _value } } set { lock.withWriteLock { _value = newValue } } } } The multithreaded code: let counter = ThreadSafeVar(value: 0) // this code might be called from several threads counter.value += 1 if (counter.value == someValue) { // do something } At first glance, everything is synced and appears as if it should work as expected, since ThreadSaveVar wraps counter and makes it thread safe. Unfortunately, this is not true, as two threads might reach the increment line simultaneously and counter.value == someValue will never become true as a result. As a workaround, we can make ThreadSafeCounter which returns its value after incrementing: class ThreadSafeCounter { private var value: Int32 = 0 func increment() -> Int { return Int(OSAtomicIncrement32(&value)) } } Case 2 struct SynchronizedDataArray { private let synchronizationQueue = dispatch_queue_create("queue_name", nil) private var _data = () var data: { var dataInternal = () dispatch_sync(self.synchronizationQueue) { dataInternal = self._data } return dataInternal } mutating func append(item: DataType) { appendItems() } mutating func appendItems(items: ) { dispatch_barrier_sync(synchronizationQueue) { self._data += items } } } In this case, dispatch_barrier_sync was used to sync access to the array. This is a favorite pattern to ensure access synchronization. Unfortunately, this code doesn’t take into account that struct makes a copy each time we append an item to it, thus having a new synchronization queue each time. Here, even if it looks correct at first sight, it might not work as expected. It also requires a lot of work to test and debug it, but in the end, you can improve your app speed and responsiveness.

Common Mistake #4: Not Knowing Pitfalls of Mutable Objects

Swift is very helpful in avoiding mistakes with value types, but there are still a lot of developers who use Objective-C. Mutable objects are very dangerous and can lead to hidden problems. It is a well-known rule that immutable objects should be returned from functions, but most developers don’t know why. Let’s consider the following code: // Box.h @interface Box: NSObject @property (nonatomic, readonly, strong) NSArray *boxes; @end // Box.m @interface Box() @property (nonatomic, strong) NSMutableArray *m_boxes; - (void)addBox:(Box *)box; @end @implementation Box - (instancetype)init { self = ; if (self) { _m_boxes = ; } return self; } - (void)addBox:(Box *)box { ; } - (NSArray *)boxes { return self.m_boxes; } @end The code above is correct, because NSMutableArray is a subclass of NSArray. So what can go wrong with this code? The first and the most obvious thing is that another developer might come along and do the following: NSArray *childBoxes = ; if (]) { // add more boxes to childBoxes } This code will mess up your class. But in that case, it’s a code smell, and it’s left up to that developer to pick up the pieces. Here is the case, though, that is much worse and demonstrates an unexpected behavior: Box *box = init]; NSArray *childBoxes = ; init]]; NSArray *newChildBoxes = ; The expectation here is that  > , but what if it is not? Then the class is not well designed because it mutates a value that was already returned. If you believe that inequality should not be true, try experimenting with UIView and . Luckily, we can easily fix our code, by rewriting the getter from the first example: - (NSArray *)boxes { return ; }

Common Mistake #5: Not Understanding How iOS NSDictionary Works Internally

If you ever worked with a custom class and NSDictionary, you might realize you cannot use your class if it doesn’t conform to NSCopying as a dictionary key. Most developers have never asked themselves why Apple added that restriction. Why does Apple copy the key and use that copy instead of the original object? The key to understanding this is figuring out how NSDictionary works internally. Technically, it’s just a hash table. Let’s quickly recap how it works on a high level while adding an Object for a Key (table resizing and performance optimization is omitted here for simplicity): Step 1: It calculates hash(Key). Step 2: Based on the hash, it looks for a place to put the object. Usually, this is done by taking the modulus of the hash value with the dictionary length. The resulting index is then used to store the Key/Value pair. Step 3: If there is no object in that location, it creates a linked list and stores our Record (Object and Key). Otherwise, it appends Record to the end of the list. Now, let’s describe how a record is fetched from the dictionary: Step 1: It calculates hash(Key). Step 2: It searches a Key by hash. If there is no data, nil is returned. Step 3: If there is a linked list, it iterates through the Object until . With this understanding of what is occurring under the hood, two conclusions can be drawn: If the Key’s hash changes, Record should be moved to another linked list. Keys should be unique. Let’s examine this on a simple class: @interface Person @property NSMutableString *name; @end @implementation Person - (BOOL)isEqual:(id)object { if (self == object) { return YES; } if (!]) { return NO; } return ; } - (NSUInteger)hash { return ; } @end Now imagine NSDictionary doesn’t copy Keys: NSMutableDictionary *gotCharactersRating = init]; Person *p = init]; p.name = @"Job Snow"; gotCharactersRating = @10; Oh! We have a typo there! Let’s fix it! p.name = @"Jon Snow"; What should happen with our dictionary? As the name was mutated, we now have a different hash. Now our Object lies in the wrong place (it still has the old hash value, as the Dictionary doesn’t know about the data change), and it’s not really clear what hash we should use to lookup data in the dictionary. There could be an even worse case. Imagine if we already had “Jon Snow” in our dictionary with a rating of 5. The dictionary would end up with two different values for the same Key. As you can see, there are many problems that can arise from having mutable keys in NSDictionary. The best practice to avoid such issues is to copy the object before storing it, and to mark properties as copy. This practice will also help you to keep your class consistent.

Common Mistake #6: Using Storyboards Instead of XIBs

Most new iOS developers follow Apple’s suggestion and use Storyboards by default for the UI. However, there are a lot of drawbacks and only a few (debatable) advantages in using Storyboards. Storyboard drawbacks include: It’s really hard to modify a Storyboard for several team members. Technically, you can use many Storyboards, but the only advantage, in that case, is making it possible to have segues between controllers on the Storyboard. Controllers and segues names from Storyboards are Strings, so you have to either re-enter all those Strings throughout your code (and one day you will break it), or maintain a huge list of Storyboard constants. You could use SBConstants, but renaming on the Storyboard is still not an easy task. Storyboards force you into a non-modular design. While working with a Storyboard, there is very little incentive to make your views reusable. This may be acceptable for the minimum viable product (MVP) or quick UI prototyping, but in real applications you might need to use the same view several times across your app. Storyboard (debatable) advantages: The whole app navigation can be seen at a glance. However, real applications can have more than ten controllers, connected in different directions. Storyboards with such connections look like a ball of yarn and don’t give any high-level understanding of data flows. Static tables. This is the only real advantage I can think of. The problem is that 90 percent of static tables tends to turn into dynamic tables during app evolution and a dynamic table can be more easily handled by XIBs.

Common Mistake #7: Confusing Object & Pointer Comparison

While comparing two objects, we can consider two equality: pointer and object equality. Pointer equality is a situation when both pointers point to the same object. In Objective-C, we use ==operator for comparing two pointers. Object equality is a situation when two objects represent two logically identical objects, like the same user from a database. In Objective-C, we use isEqual, or even better, type specific isEqualToString, isEqualToDate, etc. operators for comparing two objects. Consider the following code: NSString *a = @"a"; // 1 NSString *b = @"a"; // 2 if (a == b) { // 3 NSLog(@"%@ is equal to %@", a, b); } else { NSLog(@"%@ is NOT equal to %@", a, b); } What will be printed out to the console when we run that code? We will get a is equal to b, as both objects a and b are pointing to the same object in memory. But now let’s change line #2 to: NSString *b = copy]; Now we get a is NOT equal to b since these pointers are now pointing to different objects even though those objects have the same values. This problem can be avoided by relying on isEqual, or type specific functions. In our code example, we should replace line #3 with following code for it to always work properly: if () {

Common Mistake #8: Using Hardcoded Values

There are two primary problems with hardcoded values: It’s often not clear what they represent. They need to be re-entered (or copied and pasted) when they need to be used in multiple places in the code. Consider the following example: if ( timeIntervalSinceDate:self.lastAppLaunch] // do something } or ; ... ; What does 172800 represent? Why is it being used? It is probably not obvious that this corresponds to the number of seconds in 2 days (there are 24 x 60 x 60, or 86,400, seconds in a day). Rather than using hardcoded values, you could define a value using the #define statement. For example: #define SECONDS_PER_DAY 86400 #define SIMPLE_CELL_IDENTIFIER @"SimpleCell" #define is a preprocessor macro that replaces the named definition with its value in the code. So, if you have #define in a header file and import it somewhere, all occurrences of the defined value in that file will be replaced too. This works well, except for one issue. To illustrate the remaining problem, consider the following code: #define X = 3 ... CGFloat y = X / 2; What would you expect the value of y to be after this code executes? If you said 1.5, you are incorrect. y will be equal to 1 (not 1.5) after this code executes. Why? The answer is that #define has no information about the type. So, in our case, we have a division of two Int values (3 and 2), which results in an Int (i.e., 1) which is then cast to a Float. This can be avoided by using constants instead which are, by definition, typed: static const CGFloat X = 3; ... CGFloat y = X / 2; // y will now equal 1.5, as expected

Common Mistake #9: Using Default Keyword in a Switch Statement

Using the default keyword in a switch statement can lead to bugs and unexpected behavior. Consider the following code in Objective-C: typedef NS_ENUM(NSUInteger, UserType) { UserTypeAdmin, UserTypeRegular }; - (BOOL)canEditUserWithType:(UserType)userType { switch (userType) { case UserTypeAdmin: return YES; default: return NO; } } The same code written in Swift: enum UserType { case Admin, Regular } func canEditUserWithType(type: UserType) -> Bool { switch(type) { case .Admin: return true default: return false } } This code works as intended, allowing only Admin users to be able to change other records. However, what might happen we add another user type Manager that should be able to edit records as well? If we forget to update this switch statement, the code will compile, but it will not work as expected. However, if the developer used enum values instead of the default keyword from the very beginning, the oversight will be identified at compile time, and could be fixed before going to test or production. Here is the good way to handle this in Objective-C: typedef NS_ENUM(NSUInteger, UserType) { UserTypeAdmin, UserTypeRegular, UserTypeManager }; - (BOOL)canEditUserWithType:(UserType)userType { switch (userType) { case UserTypeAdmin: case UserTypeManager: return YES; case UserTypeRegular: return NO; } } The same code written in Swift: enum UserType { case Admin, Regular, Manager } func canEditUserWithType(type: UserType) -> Bool { switch(type) { case .Manager: fallthrough case .Admin: return true case .Regular: return false } }

Common Mistake #10: Using NSLog for Logging

Many iOS developers use NSLog in their apps for logging, but most of the time this is a terrible mistake. If we check the Apple documentation for the NSLog function description, we will see it is very simple: void NSLog(NSString *format, ...); What could possibly go wrong with it? In fact, nothing. However, if you connect your device to the XCode Organizer, you’ll see all your debug messages there. For this reason alone, you should never use NSLog for logging: it’s easy to show some unwanted internal data, plus it looks unprofessional. Better approach is to replace NSLogs with configurable CocoaLumberjack or some other logging framework.

Wrap Up

Okay, so you want to build an app for your business. You think you have an idea that can be very successful and you are ready to go to any length to turn into a reality. There are plenty of things that you can start from but here are 6 things that many fail to consider which has resulted in them crashing and burning without traces.

Not Doing Market Research

Every entrepreneurship app business starts with an idea. It is almost impossible to come up with an idea that is unique and perfect in every way. However, the key always lies with doing enough research. Market research can help you understand your customers and their needs. It would also help you to understand the gaps that other similar apps aren’t filling in and your idea in its own way can bridge that gap. The most important question that needs to be answered is, whether your idea is trying to fix a problem that is not existent. In other words, don’t try to solve a problem that is not there. Market research can help you know the answer to this question.

Not Doing Market Research Before you build an application do a thorough research. It is advisable to seek professional help to do the research. It is more likely to yield results that will help you align your app more with the market trends and needs.

Not Studying Your Competitors

“Only a fool learns from his own mistakes. The wise man learns from the mistakes of others.” ― Otto von Bismarck As mentioned earlier it is near to impossible to come up with an idea that is unique and perfect in every way. There are very few instances where people have succeeded. For every idea that was ever conceived, there are probably many similar ideas that were already tried and tested with varying degrees of success.

Studying Your Competitors Studying your competitors should be one of the most important things on your to-do list. This study should include your competitors who have succeeded and the ones that have failed. Understanding the reasons behind their success, why are they so popular? why do users love it? are some of the questions you need to find the answers for. Similarly, you need to find out the reasons for a competitor’s failure.

Not Having a Business Plan

Have a Business Plan So you have done all the research necessary for your idea. You know your market and your competitors in and out. The next important thing is to have a business plan. Not having a business plan can cause many undesired results. While business plans can help you get a direction, set goals and plan for possible bumps along the road, always sticking to a plan can also be a problem. Every market tends to evolve and change continuously. A business plan can sometimes become outdated within days. So devising a plan that helps your company in the long run, being flexible and improvising as you go are always key things to consider before you begin.

Not Doing a Proper Development

So you have done your market research, studied your competitors and have come up with the perfect business plan for your app company. The next step would be to build the app launch it. But it may not be as simple as it looks. Ideally, anyone would like to develop an app on multiple platforms. It can help you reach more customers, more downloads and more revenue. In reality, developing an app for many platforms at once can be very difficult. Any app that is built has to undergo countless modifications quite frequently. Apps are modified based on user behavior and concentrating all your resources on a single platform at a time yields better results. Considering the pros and cons of all platforms is inherent.

After building an app, not testing it enough can often be disastrous. Ensuring the app goes through enough beta testing is essential before launch.

Not Marketing Enough

Marketing Plan All apps whether they are great or average need marketing. Marketing can either make or break your app. A good app can be innovative and add value to the customer but to convince a customer to download your app is not a cake walk. A good marketing plan should know its market and target audience. It is also important that your app as a brand is more accessible to customers. Whether you decide to charge your customer for downloading or monetize your app while giving it for free is up to you. However, allowing customers to use it on a trial basis can help you grow your customer base.

Not Focusing On Customer Base

Customer Base Retention has always been a problem with every industry and the mobile app industry is no different. While growing the customer base is important for any app developer, retaining them is more important. In an era where the attention span of humans is shorter than goldfish, attracting customers is nothing short of climbing a mountain. Consequently retaining the customers is entirely a different level of hardship. Engaging with the customers enough and acknowledging them are very important. App personalization needs to happen on a regular basis and customer inputs and suggestions should be considered at every turn. It is vital to understand the reasons behind customers’ decision to leave your app or continue using it. With more retention comes more downloads.

Final Thoughts

Okay, so you want to build an app for your business. You think you have an idea that can be very successful and you are ready to go to any length to turn into a reality. There are plenty of things that you can start from but here are 6 things that many fail to consider which has resulted in them crashing and burning without traces.

Not Doing Market Research

Every entrepreneurship app business starts with an idea. It is almost impossible to come up with an idea that is unique and perfect in every way. However, the key always lies with doing enough research. Market research can help you understand your customers and their needs. It would also help you to understand the gaps that other similar apps aren’t filling in and your idea in its own way can bridge that gap. The most important question that needs to be answered is, whether your idea is trying to fix a problem that is not existent. In other words, don’t try to solve a problem that is not there. Market research can help you know the answer to this question.

Not Doing Market Research Before you build an application do a thorough research. It is advisable to seek professional help to do the research. It is more likely to yield results that will help you align your app more with the market trends and needs.

Not Studying Your Competitors

“Only a fool learns from his own mistakes. The wise man learns from the mistakes of others.” ― Otto von Bismarck As mentioned earlier it is near to impossible to come up with an idea that is unique and perfect in every way. There are very few instances where people have succeeded. For every idea that was ever conceived, there are probably many similar ideas that were already tried and tested with varying degrees of success.

Studying Your Competitors Studying your competitors should be one of the most important things on your to-do list. This study should include your competitors who have succeeded and the ones that have failed. Understanding the reasons behind their success, why are they so popular? why do users love it? are some of the questions you need to find the answers for. Similarly, you need to find out the reasons for a competitor’s failure.

Not Having a Business Plan

Have a Business Plan So you have done all the research necessary for your idea. You know your market and your competitors in and out. The next important thing is to have a business plan. Not having a business plan can cause many undesired results. While business plans can help you get a direction, set goals and plan for possible bumps along the road, always sticking to a plan can also be a problem. Every market tends to evolve and change continuously. A business plan can sometimes become outdated within days. So devising a plan that helps your company in the long run, being flexible and improvising as you go are always key things to consider before you begin.

Not Doing a Proper Development

So you have done your market research, studied your competitors and have come up with the perfect business plan for your app company. The next step would be to build the app launch it. But it may not be as simple as it looks. Ideally, anyone would like to develop an app on multiple platforms. It can help you reach more customers, more downloads and more revenue. In reality, developing an app for many platforms at once can be very difficult. Any app that is built has to undergo countless modifications quite frequently. Apps are modified based on user behavior and concentrating all your resources on a single platform at a time yields better results. Considering the pros and cons of all platforms is inherent.

After building an app, not testing it enough can often be disastrous. Ensuring the app goes through enough beta testing is essential before launch.

Not Marketing Enough

Marketing Plan All apps whether they are great or average need marketing. Marketing can either make or break your app. A good app can be innovative and add value to the customer but to convince a customer to download your app is not a cake walk. A good marketing plan should know its market and target audience. It is also important that your app as a brand is more accessible to customers. Whether you decide to charge your customer for downloading or monetize your app while giving it for free is up to you. However, allowing customers to use it on a trial basis can help you grow your customer base.

Not Focusing On Customer Base

Customer Base Retention has always been a problem with every industry and the mobile app industry is no different. While growing the customer base is important for any app developer, retaining them is more important. In an era where the attention span of humans is shorter than goldfish, attracting customers is nothing short of climbing a mountain. Consequently retaining the customers is entirely a different level of hardship. Engaging with the customers enough and acknowledging them are very important. App personalization needs to happen on a regular basis and customer inputs and suggestions should be considered at every turn. It is vital to understand the reasons behind customers’ decision to leave your app or continue using it. With more retention comes more downloads.

Final Thoughts