Posts Tagged ‘mobile apps’
There are many instances where you would need to support multiple configurations within your iOS app beyond the standard debug and release project configuration. Let’s suppose you app needs to talk to different server deployments – Development, QA and Production. In this case , you would want your app targeted for a specific environment to be configured to talk to the appropriate server deployment. This blog post describes how you can do that within your swift iOS app. Things are slightly different with Obj-C, where you could define preprocessor flags within your .xcconfig files created for each environment . But with limited support for macros in swift, we will follow a slightly different approach
Step 1: Create desired configurations for Dev, QA and Prod
- Under Project-Demo , add new configurations based upon existing Debug and Release configurations.
- Duplicate the Debug configuration as a “Dev” configuration and duplicate the Release configuration as “QA” and “Prod” configurations .
- Delete the Debug and Release configuration
Step 2: Add new schemes for Dev, QA and Prod configurations
Step 3: Make sure that the schemes created in Step 2 are “visible”
Step 4: Edit schemes created in Step2 and associate it with the appropriate configuration
So associate the QA scheme with QA configuration , the Dev scheme with Dev configuration and the Prod scheme with Prod configuration. 
Step 5: Add a new user-defined build setting under Build Settings under tab.
This setting has a different value for each of the configurations. 
Step 6: Add a info.plist property corresponding to the user-defined setting
Step 7: In your app, read the info.plist property
That's it. Take appropriate actions depending on the configuration setting.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool { // Override point for customization after application launch. let deployName = Bundle.main.object(forInfoDictionaryKey: "Deployment") as! String switch deployName { case "DEV": print ("Dev Deployment. Connect to Dev server") case "QA": print ("QA Deployment. Connect to Dev server") case "PROD": print ("Prod Deployment. Connect to Dev server") default: print("Unsupported") } return true } |
A demo project can be downloaded from here.
My Talk on Mobile Development At Girl Develop It
I had an awesome time presenting on Mobile Development at Girl Develop It, Ann Arbor group. There was an incredible level of interest in this topic that explained the good turnout despite the stormy weather.
The talk covered the basics of developing native apps for the iOS, Android and Windows platforms. In addition, an overview of some of the major cross-platform tools and frameworks including Appcelerator Titanium, Cordova PhoneGap and Xamarin Mono were provided. The talk also briefly addressed the concept of Responsive Web Design as it applies to mobile website and web apps.
You can download a copy of the talk from here and video of presentation is available on YouTube
Now a brief note on the evening itself : The topic of "Women in Technology" (or lack thereof) has always been an important to me and I am always looking for opportunities to help bridge the gender gap.
So it was encouraging to be speaking to an audience where women techies were in the majority (and a special shoutout to all the men who made it and showed their support to the group). Judging by the enthusiasm of the attendees, it is quite clear that women are just as curious and interested in technology as their male counterparts I believe that a forum that allows women to learn without fear of being judged and network comfortably with fellow women techies can be vital in encouraging more women to join the rest of us.
My Talk on “Intro to iOS Development” at ASEI
Today, I gave an introductory level technical talk about developing mobile apps for iOS platform at the American Society Of Engineers Of Indian Origin (ASEI), MI. The ASEI is "a two level (National and Local) non-profit organization of engineers and technical professionals of Indian origin". You can learn about them at http://www.aseimi.org. I was aware of the group but I had never attended any of their meetings, so I was not sure what to expect.
Right after work, I made the 45 mile drive to the ASEI meeting. Fighting the evening rush hour traffic, I reached there on the nick of time ; I probably made the organizers quite nervous!
There was a pretty good turn out. These were people, who just like me, had driven in from work and who probably had ten other places they'd rather be on a fall evening with picture perfect weather. I had to ensure that my talk was well worth their evening.
Soon after the featured mobile app presentation, I got started. I surveyed the room and learnt that there were less than five developers in the room. The rest of the audience was a mix of people with diverse backgrounds (different industries , different roles, varying demographics, a few were not even iPhone users).
My presentation was intended to be fairly technical , so my challenge was to make it appeal to the diverse audience. Although they were all not developers, I knew they all had one thing in common – they were very keen on learning more about iOS mobile development. I knew that was a start.
So for the next hour or so, I quickly moved through my slides. I had material for couple of hours but I tried to focus on material that would broadly appeal. Then the questions started pouring in and they were all very relevant. People were paying attention (well- at least most of them were) and it was interesting to see different perspectives.
I left the meeting with a greater sense of community.
You can download my presentation from here. It is intended to be a primer to the iOS platform and developing apps for it .
Mobile Video Streaming
Consumption of mobile streaming video is on an upward trend. Supporting video streaming on mobile platforms presents a lot of challenges, primarily due to the diversity of devices. The decisions include encodings , file formats, streaming protocol etc. Content Distribution Networks (CDNs) and video delivery platforms exist today to alleviate the process so you don't have to worry about the video delivery aspect and can focus on the mobile app that consumes the video.
However, in order to make an informed choice about the CDNs and their offerings and the video delivery platforms, a background on mobile streaming technologies is imperative.
I recently gave a presentation at the local Mobile Monday meeting that provides an overview of mobile streaming technologies, mobile platform specific requirements and the challenges. Click Here to download the presentation.
Security in a Mobile World
The list of mobile-specific security exploits that were discussed at this week’s BlackHat Technical Security conference got me a paranoid again. I did a bit of security related work a while ago. I didn’t attend the conference, so no- this isn’t a blog about the conference- sorry!
Security has always been an afterthought. Back in the day when I did some Internet related standards work, the section on “Security Considerations” was typically the most sparse chapter in the specification.
With the proliferation of connected devices ranging from smart phones, tablets, TVs, STBs, game consoles to cars, toasters, washing machines, refrigerators, we are susceptible to security threats more than ever. But are we taking it seriously enough?
There is no denying that mobile computing is the present and the future, so I’d like to specifically discuss mobile devices and in particular, smart phones and tablets in this context.
The Network:
Wireless networks are ubiquitous –homes, the coffee shops, airports, airplanes, trains, maybe your entire city. Of course, this was true even in the “pre-smartphone, laptop era”. But now, there is a huge difference in terms of the number of actively connected devices. Anything you want to do, “there’s is an app for that”. A lot more people are performing a whole lot more of sensitive transactions (banking, ticketing, shopping) from their mobile devices.
It’s not an unknown fact that wireless networks are not very secure. Sure, with 802.11n we have come a long way from the vulnerable WEP and WPA security of 802.11a /b/g days, but there is no guarantee that all the wireless networks we traverse are upgraded to the latest and greatest and besides, many folks who setup their home wireless networks may not take the necessary precautions to secure their network. In places where there is no sufficient monitoring of the wireless networks, it wouldn’t be hard for someone to set up a rogue Access Point that unsuspecting users would connect to or for an attacker to launch a Denial of Service attack by exploiting RF interference.
The Device:
If you are thinking that the issues I mentioned thus far are old-school, then you may be interested in the more sophisticated form of “baseband attacks” . In this case, an attacker could potentially gain control of the device memory through malicious code installed on the device’s radio signal transmitter/receiver by posing as a legitimate cell tower!
I’d like to draw some comparisons between the iOS and Android platforms.
Both the Android and the iOS platforms have a sandbox model for running applications, which limits the extent of damage by a malware-app.
Apple to its credit has a rigorous code signing process that ensures that certificates issued by Apple are used to sign apps. Android on the other hand allows for self-signed certificates and so there is no guarantee of the identity of the signer of the app.
The approval process by Apple, while in no means intended to scrutinize app code for security breaches, at least provides some level of assurance about the quality of the application. There is no Android Marketplace approval process.
Apple disallows installation of any app that is not downloaded through its App Store (and consequently signed by Apple) and in order to allow that, one would have to jailbreak the device. On the Android, it’s very easy to install apps that are not available on the Android marketplace- just check the “Unknown Sources” box under settings to allow installation of any app and you are done.
Of course, there are security holes in both the iOS and Android kernels that can be exploited quite easily on jailbroken phones with root-level access. Attackers can then use many freely available tools to disable kernel-level security patches on jailbroken phones in order to launch their attacks.
Another point to note is that mobile devices are often connected to laptops ( and desktops?) for purposes of backup/restore/sync services. This makes the mobile devices as vulnerable as the platform that they are hooked up to.
The Services:
Furthermore, the growing relevance of cloud based services for mobile devices poses significant security risks. What prevents an attacker from harnessing the “infinite” resources on the cloud for launching DDoS attacks?
Final Thoughts
There is significant variation in the demographic of mobile device users ranging from the tech-savvy geek to the grandmother who has never used a computer to the teenager who is always online. Educating such a diverse population of the security risks involved is a daunting task. This implies that security has to be integrated into the platform -the device, the infrastructure/networks and the services. The end-user is an integral part of the solution but the hardest to manage. In addition to the consumer space, many businesses allow access to corporate services from (personal) mobile devices, making the corporate resources susceptible to security attacks by compromised devices. Security is an expensive investment for both individuals and enterprises. It’s similar to insurance- You never realize how absolutely important it is until your systems are compromised. Now that I’ve shared my thoughts, I think I will relax a little!
Mobile Web Apps or Mobile Native Apps?
This is probably one of the most commonly asked questions by folks looking to mobilize their business (probably right after what mobile platform to target).
While I have discovered a lot along the way from my own experience as a (native) mobile developer, I must add the disclaimer that this blog is also a result of discussions with a lot of smart people in this space. I thought it would be worthwhile sharing it to a potentially larger audience.
Definitions
First , a brief definition of the two- [Mobile]Native Apps are mobile applications that can be downloaded and saved onto your mobile device from where they can be loaded to run natively on your device. [Mobile]Web Apps are mobile applications that are hosted on a remote server from where they are loaded and to run within a web browser environment on your mobile device.
The list below is by no means exhaustive. It is an attempt to highlight the major advantages of the two
Why a Web App?
1) “Develop once, Run everywhere”
This implies that the web app is for most part platform agnostic. This has been widely touted as the selling point for web apps, however the statement is not entirely true. HTML5 is still in the process of standardization (http://dev.w3.org/html5/spec/Overview.html ) and as we know all too well, despite standardization efforts, ,there will undoubtedly, be variations in browser implementations across platforms. These variations will impact the behavior, performance and appearance of your web app on the various platforms. Still, while I cannot quantify this statement, one can infer that the development effort/cost will be lower than building native applications independently for each of the platforms of interest.
2) App is primarily “network data driven”
By this, I mean that the app communicates heavily with backend data servers for its various functions. Communicating large volumes of data across a bandwidth constrained wireless network is not practical (unless you have a cheap, unlimited data plan – if there is such a thing!). In this case, hosting the app in the network in the proximity of the servers will alleviate the problem.
3)Application developers want to “be in greater control”
Today, the fate of the apps is dictated (to a large extent) by the terms and conditions imposed by Apple App Store , the Android Marketplace or any of the other app storefronts. As an example, Apple’s “subscription model” imposed major restrictions on in-app purchases made from native apps which led many app developers to remove the “Buy button” from their apps. Web apps will allow you to bypass those restrictions allowing consumers to directly make purchases from their web apps. This provides developers the flexibility they need to deliver the desired service to their consumers without being encumbered by policies set forth by the application store owners. That said, while there isn’t a concept of a “web app storefront” today, one can envision that something like that would be in place when web apps become more ubiquitous. So it remains to be seen if there would be any restrictions that can impact the services rendered by web apps.
Why a native app?
1) Performance, Performance, Performance!
This statement probably needs no further explanation. If performance is an important criteria, which is typical of game apps, then native app is the way to go
2) Superior User Experience/ Interface
Native Apps leverage the hardware acceleration support for graphics available through specialized GPUs and use customized/optimized platform-specific graphics libraries , thereby resulting in a vastly superior UI experience that is hard to match by web apps using JS/HTML/CSS. I earlier mentioned “Develop once, Run Anywhere” as an advantage for web apps- However, if UI is an important consideration for your app, then note that the same “one size fits all” model will result in a sub-standard user experience on certain platforms and this would be unacceptable to users who are used to a particular level of user experience on a given platform.
3) Support for Remote Notifications
Most platforms provide some sort of remote notifications framework (eg- Apple’s PUSH Notification Framework, Android’s C2DM ) that allow registered apps to receive asynchronous from their application servers via centralized notification servers. Only native apps can register for push notifications. If this is a requirement for your app, then native apps are definitely a better fit. Alternatives for web apps like SMS or emails are not as seamless or compelling.
4)No Network Connectivity
If your app does not require network connectivity for its various functions, then offering it as a web app would impose that unnecessary requirement for it to run. Of course, HTML5 supports Application Caching that can be used to locally cache apps and run it even without a network connection. So this is probably not an issue, but the level of support may vary depending on the browser’s HTML 5 implementation.
5)Better Hardware Access & Control
Native Apps can access and control platform hardware resources like camera, accelerometers through native APIs exposed by the platform. This can be leveraged to build unique, compelling features into the apps. Although HTML5 is aimed at standardizing access to various hardware resources on the platform, the level of support is likely to be “inferior” compared to the options available to Native Apps – and by ”inferior” I mean that the platform vendors are more than likely to support access to a particular hardware resource natively prior to supporting it on their browsers. In some cases, the vendor may choose not to (for security reasons) provide access to certain hardware resources via their browsers. Besides, the level of hardware access support can vary across browser implementations.
In Summary..
There is a place for both types of apps out there. The choice greatly depends on the objective of the application and the targeted audience.