Posts Tagged ‘ios’

A Guide to Biggest Challenges in Mobile App Development

Challenges are the major part of development. As the mobile app development market is rapidly growing, it has raised users expectations. However, developing a mobile app has issues and challenges. Somehow, it has become necessary for the developers to know what would be the best for their target audience. In this article, we will try to give an overview of the challenges faced by developers while developing applications.

#1 Developing for client keeping users in mind

Image result for mobile app development When it comes to development, the developers always have dual pressure. At one side, they have to develop the app according to client’s requirement; while on other, they have to keep the end user in mind. And if you want to develop an app to stand out from the crowd, you have to include intuitive design, usable features, and graphics for an amazing user experience.

#2 Cross-platform apps

Image result for cross platform apps Neither we are living in 90s, and nor do we work on a single operating system anymore; so developing apps according to the standard device is no more a good idea. There are different devices with varying screen sizes, so developers have to to keep this thing in mind while developing an app. Developers should adopt a responsive design which is adjustable according to different screen sizes.

#3 Interactive apps

Image result for interactive apps Developing an app and designing an app are two completely different things. And you have to keep the user interaction in mind. An interactive app is more likely to be successful than a non-interactive app. But it could be a big challenge during the designing phase.

#4 Involving end user

Image result for involving end user As I said, the developer has to think about the client and the end user as well. So, it is important to connect with customers and check their feedback for important modifications. The purpose of an app is to make the end user comfortable and for this mobile app should be interactive.

#5 Battery consumption and performance

Image result for battery consumption and performance These factors play a vital role in app development. A good app is the one that consumes less battery without compromising the performance. So, first, the developers have to be clear and confident about their app. In order to do so, you should launch a beta version of the app first, so that the performance and battery issue can be solved.

#6 User experience

Image result for app user experience A successful app is the one which is easy to use and understand. Thus, a developer should keep in mind to keep it simple. There should be user manual or instructions to use it. In short, keeping it simple doesn’t mean compromising on the quality, but it means to make it easy to understand.

#7 Marketing the app

Image result for mobile app marketing Though it is not a developers task, it should be taken into consideration. Marketing turns out to be the biggest challenge, after all. A successful app is a combination of 70% marketing and 30% development. So, one should look for the right tools as well as platforms that can help you in marketing.

CONCLUSION

Overall, a mobile app is a good source of revenue, but it requires a lot of attention to survive in this highly competitive marketplace. So, the developer should work toward making it successful from the very first day to make sure the success of the app.

Current Trends for Android App Development

Smartphones are ruling the market today. According to research, the number of smartphones users will be growing from 1.5 billion to 2.5 billion in 2019. And this is the reason why the Android market is growing rapidly. There are new trends in the market every day. Let us check out the key trends of Android app development that will define how the market is changing-

#1 Web Apps + AMP

Image result for web amp Google launched Progressive Web Apps Accelerated Mobile Pages (AMP) in 2016. Web Apps are designed to open a mobile app in the browser without downloading the app. Everything is same in web apps and mobile app except it allows you to use the same app in the browser. And these web apps are developed using AMP project’s principals. AMP is an open source platform that allows one to create faster, easy to load, and high performing web apps.

#2 Augmented Reality and Virtual Reality Apps

Image result for augmented and virtual reality AR and VR apps have not created a log of buzz in 2016, but they got highly popular worldwide at the end. Augmented Reality is a technology that generates a composite view by imposing computer-generated images on user’s view of the real world. You can take the example of Pokemon Go. Another type of app that got popular in 2016 was Virtual Reality (VR) apps. These apps are a simulation of three-dimensional images that a person can interact with real-time using special electronic gadgets. Example Samsung gear, google cardboard, etc.

#3 Mobile Finance Service (MFS) Apps

Image result for mobile financial services paytm mobikwik Well, these are the easiest ones to understand. These apps have an exponential grow recently. Examples of MFS apps are PayTm, Mobiwiki, PayUmoney, etc. People prefer to use cashless transactions nowadays, and they are using mobile apps instead.

#4 Security Factor in Apps

Image result for mobile security apps There are millions of Android apps, and over 75 percent of them do not even pass security tests. These apps are easily accessible by the hackers. And Android app development companies are focusing on improving the security feature of the app. Also, many antivirus apps have come in the market like Avast, McAfee, AVG, 360 security, etc.
So, these are some of the major trends which are ruling the Android app development market in 2017. Apart from this, there are many wearable devices like Fitbit, Apple, Watch, etc.  that will rule the market.  

Swift 3.1: Swift Package Manager – Part 2

In last part of Swift 3.1 release, we discussed the major language changes, but Swift Package Manager was one of the most awaited updates. This update would have a major impact on your code as it has many new functionalities.

Image result for swift 3.1 Now, let us talk about why Swift Package Manager Updates was most awaited?

Every modern programming language has an official dependency management system. They come with an official solution for code distribution as an example RubyGems for Ruby, Composer for PHP, NPM for NodeJS, etc. But iOS used to be different, developers had to rely on third-party dependency management tools like CocoaPods and Carthage until Swift Package Manager came. Image result for swift 3.1  

Now Swift Package Manager is an official replacement for CocoaPods and Carthage. And you should be definitely using it in Swift project because-

  • It is an official package manager for Swift. It is considered to be a trusted source of the Swift packages.
  • CocoaPods and Carthage have Pros and Cons as they are managed by open-source communities, but SPM is managed by Apple. So there are fewer chances of having trouble, the developers don’t have to rely on open-source communities.
  • Though it is a major product and is still in development phase, but it will definitely grow. As it is the future, so you should consider using it as dependency manager.
  • Swift is a server side language, so SPM is expected to work on both Linux and macOS. There will be no restriction of using macOS to build and distribute Swift packages.

What is new?

1. Editable Packages

Swift 3.1 added editable packages concept in Swift Package Manager. It edits command by taking an existing package and converting it to an editable one. The editable package replaces all the canonical package’s occurrences in dependency graph. ‘–end-edit’ command can be used to revert the package manager back to canonical resolved package.

2. Version Pinning

Another amazing concept is added in Swift 3.1- version pinning package. The version pin command pins one or all dependencies like this-
$ swift package pin –all      // pins all the dependencies $ swift package pin Foo        // pins Foo at current resolved version $ swift package pin Foo –version 1.2.3  // pins Foo at 1.2.3
The developer can use the unpin command to revert to the previous package version with following commands-
$ swift package unpin —all $ swift package unpin Foo
The package manager stores the active version pin information from package.pins. If the file doesn’t exist, it creates an automatic file based on the requirements (as a part of automatic pinning process) specified in the package manifest. Image result for swift 3.1

3. Other Bits

The reset command of swift package resets a package back completely. There will be no dependencies checked out or built artifacts present after resetting them. And the swift test — parallel command executes tests in parallel.

4. Multiple Return Functions

The new package has disable the C functions which return twice such as vfork and setjmp. They change the control flow of the program. So the swift community is no longer supporting them, and using them results in compile-time error.

5. Disabled Auto-Linking

THE SPM has also disabled the auto-linking feature of module maps for C language targets-
  1. // Swift 3.0
  2. module MyCLib {
  3.    header “foo.h”
  4.    link “MyCLib”
  5.    export *
  6. }
  1. // Swift 3.1
  2. module MyCLib {
  3.    header “foo.h”
  4.    export *
  5. }

What next?

Swift 3.1 is a polished version of swift 3.0 with many new features. But as the technology changes and advances every single day, we can expect many more serious changes in Swift 4.0 later. These changes could include improvement in generics, regular expression, ergonomic string design, etc.

How Swift 3.1 is different from earlier version? – Part 1

As most of the developers know that Swift is a general-purpose programming language. It is built using a modern approach to safety, performance, and software design patterns. And if you are already an iOS developer, you are already familiar with these things! Recently, a beta version of Xcode 8.3 and Swift 3.1 was released with Swift Package Manager features and improvements to the language. In this article we will majorly discuss about the Language improvements, rest will be covered in other part of the article. Let us check out the most significant features and changes in Swift 3.1 as it will have a major impact on your code!

Introduction

Swift 3.1 has downward compatibility, a person can work on lower versions codes of Swift. All you need to do is to migrate your project to Swift 3.0 using Edit\Convert\To Current Swift Syntax in Xcode. Start Xcode, select File-> New-> Playground. Choose iOS as the platform, you can call it whatever you want, and save it wherever you want.

Language Improvements

There are a number of languages improvements in this release. It includes failable initializers for numeric types, new sequence functions, and more. Let us check them out-

1. Failable Numeric Conversion Initializers

The new version implements failable initializers for all numeric types such as Int, UInt, Float, Double, etc. It either completes successfully without losing any information or simply returns NIL. This feature helps while dealing with loosely typed data conversion from external sources in a safe and recoverable manner. Just check it out by processing this JSON code-
  1. class Student {
  2.  let name: String
  3.  let grade: Int
  4.  
  5.  init?(json: [String: Any]) {
  6.    guard let name = json[“name”] as? String,
  7.          let gradeString = json[“grade”] as? String,
  8.          let gradeDouble = Double(gradeString),
  9.          let grade = Int(exactly: gradeDouble)  // <– 3.1 feature here
  10.    else {
  11.        return nil
  12.    }
  13.    self.name = name
  14.    self.grade = grade
  15.  }
  16. }
  17. func makeStudents(with data: Data) -> [Student] {
  18.  guard let json = try? JSONSerialization.jsonObject(with: data, options: .allowFragments),
  19.        let jsonArray = json as? [[String: Any]] else {
  20.    return []
  21.  }
  22.  return jsonArray.flatMap(Student.init)
  23. }
 
  1. let rawStudents = “[{\”name\”:\”Ray\”, \”grade\”:\”5.0\”}, {\”name\”:\”Matt\”, \”grade\”:\”6\”},
  2.                    {\”name\”:\”Chris\”, \”grade\”:\”6.33\”}, {\”name\”:\”Cosmin\”, \”grade\”:\”7\”},
  3.                    {\”name\”:\”Steven\”, \”grade\”:\”7.5\”}]”
  4. let data = rawStudents.data(using: .utf8)!
  5. let students = makeStudents(with: data)
  6. dump(students) // [(name: “Ray”, grade: 5), (name: “Matt”, grade: 6), (name: “Cosmin”, grade: 7)]
Here, failable initializer is used to convert the grade property from Double to Int inside the Student class.
let grade = Int(exactly: gradeDouble)
If gradeDouble is a fractional value, it will fail. It will succeed only if the value can be represented exactly as an integer.

2. New Sequence Functions

There are two new functions for data filtering to the standard library’s Sequence protocol- prefix(while:) and drop(while:). Consider the Fibonacci infinite sequence:
  1. let fibonacci = sequence(state: (0, 1)) {
  2.  (state: inout (Int, Int)) -> Int? in
  3.  defer {state = (state.1, state.0 + state.1)}
  4.  return state.0
  5. }
  Swift 3.0 simply specify the iteration count to iterate through the Fibonacci sequence-
  1. // Swift 3.0
  2. for number in fibonacci.prefix(10) {
  3.  print(number)  // 0 1 1 2 3 5 8 13 21 34
  4. }
Swift 3.1 lets you use prefic(while:) and drop(while:) with a condition to get all the elements of the sequence between two given values.
  1. // Swift 3.1
  2. let interval = fibonacci.prefix(while: {$0 < 1000}).drop(while: {$0 < 100})
  3. for element in interval {
  4.  print(element) // 144 233 377 610 987
  5. }
In the code, prefix(while:) returns the longest sub-sequence which satisfies a certain predicate. while drop(while:) does the opposite.  

3. Concrete Constrained Extensions

Swift 3.1 extended generic type with a concrete type constraint. Previously, it could not extend a type like this due to protocol constraint. Example- Ruby on Rails provides isBlank method for checking for user input. Let us check out how it would be implemented in Swift 3.0 as a computed property on the String data type extension:
  1. // Swift 3.0
  2. extension String {
  3.  var isBlank: Bool {
  4.    return trimmingCharacters(in: .whitespaces).isEmpty
  5.  }
  6. }
  7. let abc = ” “
  8. let def = “x”
  9. abc.isBlank // true
  10. def.isBlank // false
If you want the isBlank computed property to work with optional strings as well, you would do the following in Swift 3.0:
  1. // Swift 3.0
  2. protocol StringProvider {
  3.  var string: String {get}
  4. }
  5. extension String: StringProvider {
  6.  var string: String {
  7.    return self
  8.  }
  9. }
  10. extension Optional where Wrapped: StringProvider {
  11.  var isBlank: Bool {
  12.    return self?.string.isBlank ?? true
  13.  }
  14. }
  15. let foo: String? = nil
  16. let bar: String? = ”  “
  17. let baz: String? = “x”
  18. foo.isBlank // true
  19. bar.isBlank // true
  20. baz.isBlank // false
Swift 3.1 lets you extend a concrete type instead of a protocol like this:
  1. // Swift 3.1
  2. extension Optional where Wrapped == String {
  3.  var isBlank: Bool {
  4.    return self?.isBlank ?? true
  5.  }
  6. }
It is better than earlier versions because it does the same work in fewer lines.

4. Nested Generics

The new version allows you to mix nested types with generics. Understanding it with an example would be easier when an article is posted on a website, the actual coding behind looks like this-
  1. class Team<T> {
  2.  enum TeamType {
  3.    case swift
  4.    case iOS
  5.    case macOS
  6.  }
  7.  
  8.  class BlogPost<T> {
  9.    enum BlogPostType {
  10.      case tutorial
  11.      case article
  12.    }
  13.    
  14.    let title: T
  15.    let type: BlogPostType
  16.    let category: TeamType
  17.    let publishDate: Date
  18.    
  19.    init(title: T, type: BlogPostType, category: TeamType, publishDate: Date) {
  20.      self.title = title
  21.      self.type = type
  22.      self.category = category
  23.      self.publishDate = publishDate
  24.    }
  25.  }
  26.  
  27.  let type: TeamType
  28.  let author: T
  29.  let teamLead: T
  30.  let blogPost: BlogPost<T>
  31.  
  32.  init(type: TeamType, author: T, teamLead: T, blogPost: BlogPost<T>) {
  33.    self.type = type
  34.    self.author = author
  35.    self.teamLead = teamLead
  36.    self.blogPost = blogPost
  37.  }
  38. }
  We nest BlogPost inner class within Team outer class and make both classes generic. And this is how it looks like-
  1. Team(type: .swift, author: “Cosmin Pupăză”, teamLead: “Ray Fix”,
  2.     blogPost: Team.BlogPost(title: “Pattern Matching”, type: .tutorial,
  3.     category: .swift, publishDate: Date()))
  4. Team(type: .swift, author: “Cosmin Pupăză”, teamLead: “Ray Fix”,
  5.     blogPost: Team.BlogPost(title: “What’s New in Swift 3.1?”, type: .article,
  6.     category: .swift, publishDate: Date()))
  Whereas it could be simplified. Nested inner type can inherit the parent’s class type by default if the nested inner type uses the generic outer one. Therefore you don’t have to declare it, like so:
  1. class Team<T> {
  2.  // original code
  3.  
  4.  class BlogPost {
  5.    // original code
  6.  }  
  7.  
  8.  // original code
  9.  let blogPost: BlogPost
  10.  
  11.  init(type: TeamType, author: T, teamLead: T, blogPost: BlogPost) {
  12.    // original code   
  13.  }
  14. }

5. Convert Non-Escaping Closures to Escaping Ones

In Swift 3.0, closure arguments were made non-escaping to function by default, while you can convert non-escaping closures to escaping ones temporarily by using withoutActuallyEscaping() helper function in Swift 3.1. Let us understand this with an example-
  1. func perform(_ f: () -> Void, simultaneouslyWith g: () -> Void,
  2.             on queue: DispatchQueue) {
  3.  withoutActuallyEscaping(f) { escapableF in     // 1
  4.    withoutActuallyEscaping(g) { escapableG in
  5.      queue.async(execute: escapableF)           // 2
  6.      queue.async(execute: escapableG)     
  7.      queue.sync(flags: .barrier) {}             // 3
  8.    }                                            // 4
  9.  }
  10. }
This function runs two closures simultaneously and then returns when both are done.
  1. f and g come in as non-escaping and are converted to escapableF and escapableG.
  2. async(execute:) calls require escaping closures. Fortunately, you have those because of the previous step.
  3. By running sync(flags: .barrier), you ensure that the async(execute:) methods are completely done and the closures won’t be called later on.
  4. Scope limits the use of escapableF and escapableG.
If you squirrel either temporary escaping closures away (i.e. actually escaped them) it would be a bug. There are many other changes in Swift 3.1. They include Swift Package Manager Updates, Multiple-Return Functions, Disable Auto-Linking, etc. We will be discussing it in next part. Till then share your views with use!  

5 Common Myths About Mobile App Development

The mobile application development industry is expanding, so are different myths about it. The industry has gone through many leaps and bounds recently. The reasons behind misconceptions could be half knowledge, hearsay, and past experience. While developing an application different problems and bugs come up which they are not obvious. People generally consider that these errors and bugs are similar, and this is what encourage myths. These misconceptions start from the sources or companies who could not get what they exactly want. They are generally old presumptions or because of out-of-date ideas which are not correct. And this why, the expansion of this industry has led to many misunderstandings relating to this line of business. In the following piece, we may be debunking a few of these myths:

Myth 1: In-house app development takes same time as the outsourced companies take

Image result for inhouse app development vs outsourcing Well, the reality is completely opposite. Developing an application yourself will take exactly 3-4 times the amount of minimum time you decided. Outsourcing the work would give you 90% results as there will be professionalism. Some companies decide to develop the app themselves to save money and time which ultimately turns out to be a bad idea.

Myth 2: Mobile app development is inexpensive

Image result for mobile app development is inexpensive Yes, the mobile apps are more compact in size than regular internet application, but it doesn’t make it less expensive. In fact, developing a mobile app need more expertise than any other app. The major cost needs to be sustained to employ or the expertise of a mobile application agency and getting software developed. The only already built thing available for free are the application quotes. Apart from this, the developers need to work it out themselves. So, the fact is mobile applications are not inexpensive.

Myth 3: Mobile apps develop their own demand

Image result for mobile app marketing Going by the facts and numbers, it is not as simple as it looks. A mobile application has to compete with many other similar applications. In order to come into the market, your marketing campaign needs to be strong enough to stand out from the competitors. Users just don’t rush into downloading applications on their phone as soon as they are released. So, you need to make sure that you marketing campaign attracts the users.

Myth 4: Building customised application demands a lot of programming

Image result for mobile app programming This myth has become everyone’s favourite, but let us come down to the reality. According to today’s scenario, most of the companies require minimum programming to build a solution. Companies need to accept the reality that company’s flexibility is more about the platform and incorporation than improvement, creation and release mobility solutions in a small fraction of the time and cost of standard solutions.

Myth 5: Facilities require huge investment

Image result for mobile app upgradation investment Though investment is required, but it is the poor planning of companies which lead to this myth. Most of the companies think that adding more servers is the solution to every problem. While you can easily provide a secure, scalable, and inexpensive solution with a cloud-based system. All you need to do is consult with an expert and make a well-planned financial strategy. These misconceptions have been flowing around the market which do not make sense. And if you are also dealing with it, you need to get out and find something better. These myths somehow degrade the quality of a mobile app, and it could be a huge disadvantage for the client and the developer as well.