Friday, February 19, 2016

Apple Worldwide Developer Relations Intermediate Certificate Expiration

According to the Apple Developer Forums, the Apple Worldwide Developer
Relations Intermediate Certificate Expiration expired on 2/14/2016.


Thanks for bringing this to the attention of the community and apologies for the issues you’ve been having. This issue stems from having a copy of the expired WWDR Intermediate certificate in both your System and Login keychains. To resolve the issue, you should first download and install the new WWDR intermediate certificate (by double-clicking on the file). Next, in the Keychain Access application, select the System keychain. Make sure to select “Show Expired Certificates” in the View menu and then delete the expired version of the Apple Worldwide Developer Relations Certificate Authority Intermediate certificate (expired on February 14, 2016). Your certificates should now appear as valid in Keychain Access and be available to Xcode for submissions to the App Store.

Follow These Simple Steps:
  1. Open Keychain from top menu go to View > Show Expired Certificates .
  2. Now In Keychain Locate Expired 
  3. Apple World Wide Developer Relation Certification Authority                                   in Login tab and System tab from left panel and delete it from both tabs.
  4. Download Certificate:         https://developer.apple.com/certificationauthority/AppleWWDRCA.cer                                   and double click to install it.
  5. Restart Xcode.

Sunday, November 8, 2015

Selecting best approach for Mobile App Development

1.    Background
There are lots of mobile app development technologies in the market, which uses deferent approaches. It’s very hard to decide which approach we should use in a particular project. What are the areas we should focus? How we gather others experience and adapt it to our company.

2.    Introduction
This post describes out come of a detail research done by evaluating current mobile development approaches and related technologies used by the international companies as well as the experiences gathered from the local companies mobile engineers. In this post I describe how to choose the best mobile app development approach and related technology platform and what are the reasons for each and every selection.

There are lots of mobile app development technologies in the market. When deciding the correct technology for the mobile app you need to have a clear idea about the use of each technology. When deciding the right technology you need to concern about the following goals,

1.     User experience
a.     High UI richness
b.     High Performance
2.     Development Cost
a.     License
b.     Training
3.     Development Time
a.     Available resource capabilities
b.     Leaning curve

At the moment most of the time you will not be able to archive all the goals, most probably you will be able to archive one of the above mentioned goals.

If you don’t have a clear idea about the approach and the technology, you will have to pay the price in the long run. For example your goal was to reduce the cost but you decide the wrong technology, then you will be end up with expending two or more times than the estimated budget.
   
3.    Development Methodologies
There are three major mobile development approaches

1.     Pure HTML5 web sites (write once, run everywhere)
2.     Hybrid (Cross platform)
3.     Native

Each and every approach has its own advantages and the disadvantages. Lets look at the each and every approach in derail by evaluating the related major development technologies available in the market.
                       
3.1 Pure HTML5 web sites
If you want a mobile solution very quick within a small budget this is the correct approach for you. But in this approach you will not able to access any mobile features except the HTML controls, which can access camera, geo location and local storage for offline work.

In this approach you can archive the concept “write once run everywhere”. But if you want different design than a desktop, web pages should be replicate the look and feel of a mobile app. For that you can user JavaScript frameworks such as jQuery Mobile or Sencha Touch. These frameworks consist with layouts, navigation patterns and transition animation and etc.

Some times you may need to customize the look and feel of the web site according to the native UI of each platform. For example iOS style controls on iOS and android style controls in android.

If you go for platform specific changes your code reuse percentage will drop to 70%-80%. But keep in mind these are not real apps the functionality is very limited. For example you can’t access the contacts, connect to third party hardware, run in background, receive push notifications and etc.

Most importantly you can’t send the web sites to the app store or google play store. Though this approach is very easy and cost effective this have significant limitations.

If the company have web development and the app is really simple such as web site being ported to mobile this is the best approach and cost saving will be 70-100% for the second platform.

3.2  Hybrid approach
If your main goal is to reduce the cost this is the best approach for you.
There are two types of hybrid apps, there are

1.     Web to Native Wrapper Hybrid app
2.     Runtime Hybrid app

3.2.1      Web to Native Wrapper - Hybrid
If you want to run your WEB app in a mobile web browser and access to more device features you can use wrapper tools to pack you app into a native container. The wrapper tools usually offer a set of extensions to some native platform APIs from your web code, enabling you to do what websites can’t do. This is like a web site without a browser frame but with extra functionality. These apps can be distributed through app stores.

The most popular wrappers are PhoneGap and Apache Cordova. At the moment if your teams have HTML/JS skills this is the quickest way to get the app into the app store.
The standard web-view used by the cordova to display your web-app on the mobile device considerably different form the native browser. Most of the time they are slower than the native web browser. It lacks JIT-compilation, making your app packed JS much slower than the browser versions or the native code. Slow down is noticeable in most aspect of UI, from the response time to touch gesture to smoothness of screen transitions and animations.

For iOS the Cordova uses UIWebView this is slower than the new safari web kit. Apple has come up with a new web view call WKWebView but at the moment Cordova has not officially updated the standard web view to new web view due to some reasons they have faced with iOS 8.

The other problem you will face is related to JavaScript and memory use. It needs a lot of memory when JS-Heavy frameworks like Sencha Touch render your UI. So the longer the user stays in the app and uses it, the more memory it’s going to take, up to the point when the OS kills your app. This will not happen to a light weight app this will happen for large applications such as social networking or business applications with lots of controls, data and transitions.

These type hybrid apps are slow. They are slow to load data, slow to process it, and even slower to respond to touch gestures. Hybrids also don’t feel like proper native apps, which often irritates users.

If you’re considering going HTML5/JS for your project, the best approach is to delivering the app through the browser or developing a simple by using the maximum amount of static HTML5 and adding JS only where necessary. Your code will run faster and users will likely be less critical and more forgiving.

“The biggest mistake we made as a company was betting too much on HTML5 as opposed to native. It just wasn’t ready.”
Mark Zuckerberg,
Founder and CEO of Facebook

When we taking about the most of the companies experience in developing this king of hybrid approach its best for simple, single-screen apps, with minimum transitions and logic, where low performance is difficult to notice. And their recordation is not try doing something more complex or optimizing app performance because it will simply eliminate the cross-platform benefits and the budget will be nearly same as pure native app.

3.2.2      Runtime Hybrid app
These types of app are not warped with a container; they are compiled into native runtimes. The performances of these types of apps are nearly similar to native apps. You get the native UI, most of the native API’s and the native performance.

At the moment there are two major competitors in the market.

1.    Appcelerator Titanium 

With Titanium app you can build fully native UI with java script. A carefully written Titanium app may offer UI performance comparable to that of native app, but its still driven by the JavaScript and its fundamental technical limitations. Its make the app’s business logic slower than it can be. In complex apps the user may see this effect as delays in screens transitions, while your JS code is loading or parsing data.

The development teams has a learning curve though the app is written by JS because it much closer to native app, the team need to have some knowledge of the native platforms as well. The team will have to use platform-targeted code.

This is decent platform, which provide native UI, but since it is built on JS there is performance issue. This performance is greater than the wrapper technologies and the less than the native apps.

If we develop an app with several screens and minimum business logic this the best approach but if we add more and more it will make performance issues. So if you optimize the app to increase the performance the cost will be nearly same as building a native app because you have to optimize it for each platform.

2.    Xamarin

As we discussed there is a performance issue due to use of JS. But Xamarin has go one-step further using C# and .NET instead of JS. With Xamarin you can modularized your code. You can separate platform specific UI code from the high level parts like business logic, data model and server integrations.


The shared code is then written just once with full reuse for all supported platforms, while all the native features are implemented via calls to native UI and the APIs independently. Xamarin provides a set of C# bindings covering 100 percent of the native APIs. The apps build using this technology is full capable of what a native app can does. For example work in background, connect to external hardware and etc.

The .NET code is compiled in to the native binaries for iOS and Android. And the code is easily ported to windows mobile.

The problem with the Xamarin the binaries slightly larger than the pure native ones, because of that the lunchtime get increased, but after fully loaded it runs much faster that JS bases app. The performance of Xamarin apps is indistinguishable from native.

The other problem is you have face is you need to do non-trivial memory management. Because the garbage collector works a bit differently from the typical .NET environment. But Xamarin offers a good set of best practices for memory and performance. Follow them from the start and you’ll be safe.

If your have mobile development resources familiar with in .NET this is the right technology for you. 

When you need maximum flexibility, performance, access to hardware, platform capabilities, or if your app is simply huge and complex, the best technology is Xamarin. It’s perfect for business applications with large amounts of logic, server-interaction and data-oriented code, and should give you around 40-60 percent of code reuse.

3.3  Native approach
If your goal is higher user experiences, which are optimum performance, high UI richness and smoothness; this is the correct approach for you. Because the native development technologies are optimizes for each specific platform. (Xcode for iOS, Eclipse for Android, VS for Windows Mobile). There for you can get the maximum possible capabilities of the mobile OS.

If you are after the best possible reliability, quality, and performance, or simply want to start with just one platform this is the right technology for you. It may cost you a bit more, but you’ll know what to expect and exactly what you’re paying for.


4.    Why mobile web apps are slow?
Actually JavaScript will not make the app slow, it’s slow in mobile devices because of the mobile processor architecture. Mobile processor uses ARM architecture where as computers use x86 architecture.

ARM processor is special designed processor for mobile devices and other kind of low power devices. It’s specially design for low power consumption. It has low number of registers than the x86 processor. And also mobile devices have limited memory when compared to computers. There for x86 is ten times faster than ARM. This is the reason the heavily used Java Script mobiles application are slow in mobile devices.


Summery
Technology
Tech Complexity – General
User Experiences
Works Best for
Code Reuse
Main Problems
HTML 5
Simple
Slow
Existing websites
70-100%
Very limited access to native features
Less native look and feel
Cant be submitted to app store
Cordova + JS framework
Simple
Very Slow
Web sits need app store,
One-Screen apps
60-90%
Poor performance
Less native look and feel
Heavy JS will make memory problems
Business logic is written in JS
Slower than the native web browser
Titanium
Medium
Acceptable
Simple apps
50%-70%
Poor performance
Limited native feel
Business logic is written in JS
Xamarin
Very Complex
Fast
Business apps
40%-60%
Initial load time high compared to native
Have to follow best practices to avoid memory issue
Native
Complex
Best Possible
Business apps, Demanding apps
0%
Cant be reusable

5.    References