Tag Archives: ios

Best practices for improving mobile data security

IT administrators can mitigate many of the mobile data security risks associated with mobile devices and applications by instituting best practices and native security measures.

When smartphones first emerged, they offered little built-in security. With its native encryption and over-the-air device management, BlackBerry was a noteworthy exception and fostered broad business adoption, leading other manufacturers to emulate BlackBerry.

When the Apple iPhone launched, for example, it had no encryption or IT management hooks. Today, every Apple iOS device comes with an encrypted file system, can be locked with a long, complex pass­code and supports more than 150 IT-configurable poli­cies. Although such native capabilities vary by device make and model, all four major mobile OSes — Apple iOS, Google Android, BlackBerry and Microsoft Windows Phone 8 — support those best practices and more.

Mobile data security best practices

PIN or passcode. The first line of defense against the unauthorized use of a lost or stolen device is a robust PIN or passcode. All four OSes support numeric PINs and alphanumeric passcodes. The primary challenge is enforcing long, complex passcodes that users must re-enter frequently. Pairing shorter passcodes with secondary user authentication to open every sensitive business application is a practical way to reduce risk.

Remote find and wipe. Most employers also want the ability to remotely locate a lost or stolen device and, when warranted, wipe all corporate data. Again, all four OSes support remote find and wipe, but wipe effectiveness varies. For example, wiping an iOS device renders all encrypted data (personal or corporate) inaccessible. In contrast, wiping an Android device simply resets it to factory default settings, which can leave recoverable data behind. Pairing remote wipe with applications that rigorously encrypt their own data makes remote wipe more effective.

Stored data encryption. Stored data encryp­tion has become an enterprise must for mobile devices that store business data, including temporary files, mes­sage attachments, screen snapshots, cached Web pages and other data that "leaky" applications generate. Full device encryption is widely supported, though notewor­thy exceptions include Android 2.x and Windows Phone 7. Further, some devices can’t encrypt everything, even if the OS supports it. And even an encrypted device ex­poses data to a thief with a cracked PIN.

Here, best practices pair full-device encryption with software encryption by each application. To improve mobile data security and avoid leaks, application developers must be careful to rigor­ously encrypt everything written to flash storage and to safeguard their encryption keys. Emerging trends include sandboxed applications that create their own safe (authenticated, encrypted) operating environment and secure data containers that safely store IT-managed documents for offline access.

Over-the-air encryption. Employers also worry about data in motion: that continuous stream of traf­fic to and from always-connected wireless mobile devices. All four OSes natively support Transport Layer Security (TLS)-encrypted email and Web traffic, WPA2-encrypted Wi-Fi traffic and virtual private network (VPN)-encrypted network access. Unfortunately, related settings and certificates are too complicated to rely on end-user configuration. In addition, requiring secure Wi-Fi on-site doesn’t prevent users from exposing data at public Wi-Fi hotspots, and VPN configurability varies by device make and model. As a result, application developers should use TLS to encrypt their own traffic, independent of network or VPN security.

Anti-malware. The above practices focus on mobile data security, but they can also deter malware, preventing Android malware from grabbing files on removable storage accessible to all applications, for example. In addition, mobile OSes sandbox applications to insulate them from one another and require users to grant each ap­plication permission to access device features or shared data. Unfortunately, users often accept those requests without understanding the consequences. While Ap­ple’s App Store policies have deterred iOS malware, the same can’t be said for Google’s or Microsoft’s stores. Even BlackBerry users can install applications from less-trustworthy sources (a risky behavior known as sideloading).

Best practices to deter mobile malware are still emerging, but they include monitoring for blacklisted applications or compromise, routing mobile traffic through cloud services that scan for malware and running malware scanners on mobile devices. Application development best practices include self-protection of data, testing for exploitable vulnerabilities and requesting only essential permissions.

Mobile device management. IT can gain visibility into and control over smartphones and tablets with mobile device management (MDM). Methods include using Microsoft Exchange ActiveSync to require a PIN and encryption and using third-party MDM tools to config­ure and continuously enforce security policies. Sup­portable security policies vary by mobile operating system/version, device make/model and MDM tool, but centralized security policy management is necessary to implement other practices such as PIN/passcode, remote find/wipe, encryption and even anti-malware, without depending on compliant end users to always do the right thing.

Mobile application management. Increasingly, MDM tools also provide good mobile application management, letting IT inventory, deliver, install, update and remove applications. However, application developers need to understand how applications can be packaged, deployed and updated for each mobile OS, as well as the distribution rules imposed by each manufacturer and app store. Those rules have mobile data security implications — all four mobile OSes require applications to be signed, for example — but differ as to who issues the signing certificate and how that affects application permissions. The best practice here is developer education.

Data backup. To ensure that data can be restored after a device is damaged, wiped or lost, take advantage of data backup capabilities supported by each mobile OS. Native backup capabilities typically include writing backup files to a laptop or desktop and routinely backing up data to cloud storage (e.g., Apple iCloud, Google Drive). Best practices include passcode-protecting ac­cess to backup files and cloud storage, encrypting those backups wherever possible and preventing business data from being backed up to personal storage areas. Mobile application developers may want to take advantage of native backup capabilities, but they also need to consider the security implications of doing so.

As indicated, many mobile data security best practices use native mobile device and OS capabilities as a starting point, strengthened by combining those with application-specific security measures. Building security into each mobile application not only reduces risk but also levels the still-uneven playing field of mobile platforms. Mobile OS security and management hooks will con­tinue to improve, and new mobile devices will emerge with new vulnerabilities.

Further, although we have focused here on device, OS and mobile data security, mobility involves many other components that must also be secured by IT, including the wireless networks, mobile messaging servers and cloud storage accessed by mobile users. Understanding all of these mobile risks and looking for ways to offset them during mobile application development is an in­vestment.

Source: http://searchconsumerization.techtarget.com/tip/Best-practices-for-improving-mobile-data-security

Did you like this? Share it:

Apple Is Beta-Testing An Update That Kills Evasi0n Jailbreak

All good jailbreaks must come to an end.

Late last week Apple released an update for iOS to developers in beta that prevents the use of the popular jailbreak software evasi0n, according to one of evasi0n’s creators who tested the patch over the weekend, David Wang.

Wang tells me that he’s analyzed the 6.1.3 beta 2 update and found that it patches at least one of the five bugs the jailbreak exploits, namely a flaw in the operating system’s time zone settings. The beta update likely signals the end of using evasi0n to hack new or updated devices after the update is released to users, says Wang, who says he’s still testing the patch to see which other vulnerabilities exploited by the jailbreak might no longer exist in the new operating system.

“If one of the vulnerabilities doesn’t work, evasi0n doesn’t work,” he says. “We could replace that part with a different vulnerability, but [Apple] will probably fix most if not all of the bugs we’ve used when 6.1.3 comes out.”

That impending patch doesn’t mean evasi0n’s time is up, says Wang. Judging by Apple’s usual schedule of releasing beta updates to users, he predicts that it may take as long as another month before the patch is widely released.

When evasi0n hit the Web earlier this month, it quickly became the most popular jailbreak of all time as users jumped at their first chance to jailbreak the iPhone 5 and other most-recent versions of Apple’s hardware. The hacking tool was used on close to seven million devices in just its first four days online.

Despite that frenzy, Apple has hardly scrambled to stop the jailbreaking.  Evasi0n has already gone unpatched for three weeks. That’s far longer, for instance, than the nine days it took Apple to release a fix for Jailbreakme 3.0, the jailbreak tool released in the summer of 2011 for the iPhone 4, which was by some measures the last jailbreak to approach Evasi0n’s popularity.

Apple’s slow response to Evasi0n is explained in part by the relatively low security risk that the tool poses. Unlike Jailbreakme, which allowed users to merely visit a website and have their device’s restrictions instantly broken, Evasi0n requires users to plug their gadget into a PC with a USB cable. That cable setup makes it far tougher for malicious hackers to borrow Evasi0n’s tricks to remotely install malware on a user’s phone or tablet.

Security researchers have nonetheless pointed out that Evasi0n could give criminals or spies some nasty ideas. The tool uses five distinct bugs in iOS, all of which might be appropriated and combined with other techniques for malicious ends. And F-Secure researcher Mikko Hypponen points out that if a hacker used a Mac or Windows exploit to compromise a user’s PC, he or she could simply wait for the target to plug in an iPhone or iPad and use evasi0n to take over that device as well.

More likely, perhaps, is a scenario described by German iPhone security researcher Stefan Esser. He argues that a hacker could use a secret exploit to gain access to an iPhone or iPad and then install evasi0n, using the jailbreaking tool to hide his or her tracks and keep the secret exploit technique undiscovered by Apple and unpatched. “That way they protect their investment and leave no exploit code that could be analyzed for origin,” Esser wrote on Twitter.

Apple already has a more pressing security reason to push out its latest update. The patch also fixes a bug discovered earlier this month that allows anyone who gains physical access to a phone to bypass its lockscreen in seconds and access contacts and photos.

When Apple’s update arrives, the team of jailbreakers known as the evad3rs may still have more tricks in store. Wang tells me that the group has discovered enough bugs in Apple’s mobile operating system to nearly build a new iOS jailbreak even if all the bugs they currently use are fixed.

But then again, Wang says he hasn’t yet been able to check Apple’s patch for every bug it might fix–either the ones evasi0n employs or those he and his fellow hackers had hoped to keep secret for their next jailbreak. “If they patch most of the bugs,” Wang says, “Then we’re starting from scratch.”

Source: http://www.forbes.com/sites/andygreenberg/2013/02/25/apple-is-beta-testing-a-fix-for-evasi0n-jailbreak/

Did you like this? Share it:

IBM brings iPhone mobile security to the enterprise

IBM has launched new software to help developers secure code and data in iPhone and iPad apps.

AppScan Source 8.7 for iOS searches through app code and alerts developers when it finds flaws.

The software also analyses apps that employees may want to use on Apple devices for vulnerabilities and alerts IT security staff to potential threats.

Big blue said the software would improve security without sacrificing the time to market for mobile apps.

Citing Gartner figures, IBM said more than 45.6 billion mobile apps were downloaded in 2012, which is why securing smartphones and other endpoint devices should be a top priority for organisations.

IBM developed AppScan Source by looking at over 40,000 mobile APIs for iOS apps using Apple’s iOS Software Development Kit.

These API profiles have been added to the IBM AppScan Source Security Knowledgebase and tied to the analysis engine.

The software also features complete language support for Objective-C, JavaScript and Java and includes the ability to do call and data flow analysis that will generate trace information. This new capability enables organisations to build secure enterprise mobile apps, regardless of technology choice, for employees and partners.

One of the companies that has been trying out AppScan Source for IOS is mobile technology firm KiwiTech.

Rakesh Gupta, chief executive of KiwiTech, said his firm had developed hundreds of apps for iOS and Android and as the risk from mobile malware and data leakage grows, “our customers are looking for ways to secure their iOS and Android apps and protect corporate data.”

Gupta said the software would help his company “proactively secure mobile apps and automate security testing to ensure our customers can keep pace with constant updates."

Caleb Barlow, director of Application, Data and Mobile Security at IBM, said the new capability would help clients incorporate “security into their infrastructure and solutions from the design, development and testing phases rather than leaving security to become an afterthought.”

AppScan Source for iOS will be available from 25 March. IBM launched its AppScan range of products in 2008, following the $2.1 billion acquisition of Rational Software. It has previously launched a version of the software that scans Android apps.

Source: http://www.itpro.co.uk/smartphones/19276/ibm-brings-iphone-mobile-security-enterprise

Did you like this? Share it:

iPhone lock screen hack prompts another Apple patch

iPhone lock screen

Apple is once again promising to patch iOS 6.1 – this time to address a serious security flaw that allows thieves to bypass the iPhone’s lock screen.

Earlier this week Apple released iOS 6.1.1 to address a flaw that left iPhone 4S users struggling to connect to 3G networks after the upgrade to iOS 6.1. Apple has also promised a further iOS 6.1 patch to fix a problem that sees the phone repeatedly pinging Exchange servers, draining the device’s battery.

Now another more serious bug has emerged, which allows phone thieves to bypass the lock screen on the iPhone 5 without entering the correct PIN code. The rather convoluted method involves making, and then quickly terminating, an emergency phone call, before holding down the power button twice. The hack could give thieves access to a user’s contacts, voicemail and phone call history.

A YouTube video demonstrating the attack is shown below:

iphone lock screen

An Apple spokesperson told All Things Digital that the company "takes user security very seriously" and that it "will deliver a fix in a future software update".

Source: http://www.pcpro.co.uk/news/security/379981/iphone-lock-screen-hack-prompts-another-apple-patch

Did you like this? Share it:

7 Key Questions To Ask When Taking Your App From iOS To Android

HowAboutWe was boot-strapped into life in April 2010 at the apex of the iPhone’s market ascendency. Like rookies (we were rookies) we built a basic web app. No API. No native apps. No real mobile strategy. And yet, in creating HowAboutWe–a dating service in which users post the actual places they want to go on dates–we had built a mobility dream of location-based, on-the-go, high-converting repeat usage. Obviously the “offline dating site” should be the “offline dating app.” We realized this pretty quickly and so began the process of retroactively becoming a mobile-first product.

IOS was the obvious first platform. Like hundreds of thousands of other companies we built a native iPhone app. We launched it with great success; it was the number-one new featured app when it came out, has acquired hundreds of thousands of downloads, is top in in-app purchases, and has usage correlated with our very highest subscription conversion rates. We thought we could take our beautiful iPhone app, make a few tweaks for Android, and call ourselves ready for development. After all, we had seen this pattern from dozens of other highly successful apps. But after diving into design research, we realized this project would be a lot more complicated.

The seven questions below stake out a path of inquiry that will help you translating your own design language from iOS to Android.

Yes, Android is worth it
We had high hopes for Android, and it hasn’t disappointed. In December 2012, we launched HowAboutWe for Android and, in its first few weeks, the app has been installed over 20,000 times with about a 65 percent conversion rate from install to complete sign-up. We’re seeing over 10 percent conversion rates from sign-up to subscription (we launched with a seven-day free trial subscription that auto-converts into paid membership).

In fact, in some ways our Android users are showing up the folks on iOS. Key engagement rates (such as photos uploads) are 20 percent higher on Android than they are on the web. Early data indicates high repeat usage rates with an average of three sessions per day per active user. And all of this is based on the limited feature set with which we launched. We’ve come to believe strongly that Android will be a great source of ongoing user acquisition, retention, and monetization.

We seriously considered doubling up our mobile web and Android approach by building an HTML5 app and throwing it into a wrapper for Android, but our early prototypes indicated that we would never be able to achieve with a PhoneGap-type solution the kind of design elegance that was our standard. Native it was.

Around that time, two big things happened. First, Google released its Android Design Guidelines, changing the entire trajectory of our Android strategy for the better. It’s only in the last six to 12 months that Android design and development patterns have come to mature, making 2013 an auspicious time to dive into Android development.

Second, we hired a top tier in-house Android engineering team, and charged them with building an app based on Android development best practices, not a mere duplication of our iOS architecture. (The team is pictured below: Matt Lim, Chuck Greb and Baldur Gudbjornsson respectively.) They immediately set about asking and answering the following seven questions.

1. What’s the goal of cross-platform consistency?
Android, iOS, and mobile web each have their own design patterns and conventions. In designing for these platforms, the goal is to achieve both cross-platform brand consistency and alignment with the conventions specific to the platform. The truth is that almost no actual users outside your QA team will use both your iOS and Android apps, so consistency of interaction isn’t the goal. It can be annoying (at best) and downright confusing (at worst) to users to be presented with interactions that are not consistent with the general patterns followed by other apps on their phone. And yet, while you seek to avoid anti-patterns, you also want to pursue breakthrough UI innovation. This is the mogul course of cross-platform design.

Let’s take the HowAboutWe messaging interface as an example. (Below, our original iOS-like Gingerbread inbox, our Jelly Bean inbox, and our iOS inbox.)

IPhone and Android each convey essentially the same information, but the visual treatment and interactions are quite different. The primary information shown here is a list of messages, tabs for each label, read/unread status, and an indicator showing if a reply has been sent. Tapping on any of the messages opens a new screen with the full conversation thread, and some other peripheral functionality is there, too.

Android’s Action Bar follows a few key, differentiated patterns. In all three applications, tapping the top-left most icon opens the main menu of the application. But the visual treatment of these icons is quite different. Android uses the app logo (or "home" icon) and the title is left-aligned on Android, showing the “up” navigation to the left of the home icon, which indicates additional content is available.

Android also uses scrolling tabs rather than iOS style buttons to display the labels for inbox, sent, and archive, and hides additional functionality behind action icons. Rather than showing an indicator icon on unread messages like iOS, Android relies on changing the background color of the cell. Also, notice on Android the absence of the iOS convention of a right-pointing caret on each line to show it is clickable.

In short, what look like two similar views really aren’t the same from the standpoint of interaction.

Our original designs copied the iOS patterns almost exactly, but the new Android Design Guidelines called for a significantly updated, and more native UI. It was only once we internalized the native Android design patterns that we were able to get away from our original, iOS-derivative designs.

2. Which UI elements should we customize?
When should you use the system default widgets? When should you create custom widgets?

On Android, the look and feel (and sometimes even behavior) of system default components will vary significantly depending on platform version, device manufacturer, and theme. Recently, Android has been trying to reduce style inconsistencies, but this is still a significant challenge for developers.

The only way to truly ensure style and layout consistency across various platform versions, manufacturers, screen sizes and densities is by using custom UI components. This can mean anything from simply swapping a different image asset to be used as the background to coding a brand new view class with the desired look and functionality. There is an increased cost in terms of design, development, and QA time for any custom solution, but it can lead to a more consistent, brand-aligned result. (Below, side-by-side respective comparisons of similar buttons in Jelly Bean and Gingerbread; Jelly Bean and Gingerbread; Gingerbread and Jelly Bean.)

Buttons are one of the easiest components to customize, so start your customizations there. Typically, functionality for a button is not going to change. But the look and feel is drastically different between pre-Honeycomb and post-Honeycomb devices. Developers can simply drop in alternative assets for each screen density and state to make the buttons look the same across all platform versions.

We chose to customize many of the buttons that appear in HowAboutWe, and the workload was minimal because we are able to reuse the same handful of button styles throughout the app. This allows us to keep a more consistent, branded look and feel across all platform versions and devices.

Spinners (also known as dropdown menus) look very different on pre-Honeycomb devices. This can affect not only the look and feel of the individual component but the overall layout of a screen. (Above, spinners as they appear in Gingerbread, Jelly Bean, Gingerbread, and Jelly Bean respectively.)

For the screen that allows a user to edit his or her basic information, we wanted to use spinners since the user is limited to a select set of responses for most fields. However, we knew the layout would look too cluttered on Gingerbread and Froyo devices with the old big gray box style that opens a separate dialog over the screen. We customized this to create consistency. Since the theme of the application is based on Holo, we decided to use the new spinner style even on older devices. We achieved this result by creating a custom style for the spinners using the new assets from AOSP.

In some cases, customization felt too costly to be worth it, despite the consistency gains we would reap. For instance, we decided not to customize Text Fields (ex. "CAREER/JOB"), so older devices and newer devices still have a different look and feel for these components. (Above, similar screens in Gingerbread and Jelly Bean show their different text fields side-by-side.)

3. What should the home screen look like?
In designing the UI pattern for the HowAboutWe app, we wanted to provide an elegant full-screen experience, keeping navigation quarantined in a secondary area. However, we also wanted to provide the capacity for rapid switching between tasks.

Our initial designs used the fullscreen dashboard view pattern seen in the earlier version of the Facebook Android app and the 2011 Google I/O app. We eventually moved to a sliding drawer, and here’s why.

Initially, the advantages of the grid UI seemed obvious. The options are presented to the user in a simple, easy-to-digest grid. And, from an implementation standpoint, it’s fairly simple and straightforward.

However, from a user’s perspective, there are significant downsides. The navigational experience  disruptively occupies the entire screen. It makes navigation a primary act rather than a facilitative one. In this way, it’s a bit of a monolithic design choice. (Our old grid layout next to Facebook and Google’s former designs, below.)

Within the last year, the sliding drawer model has become increasingly popular, perhaps first made popular by the Twitter iPad app. Visually compelling, easeful, and fun to use, it has since been adopted by Facebook, YouTube, Google+, Path and many, many others. We decided to go with this less interruptive, more elegant pattern.

For implementation, we decided to use jfeinstein10’s public SlidingMenu library project which is available on Github here. It gave us a base FragmentActivity that hosts an easily configurable sliding drawer contained in a Fragment. This is significant because it is stateful, has access to useful lifecycle methods, and allows clean interaction between itself and its hosting activity.  When opened, the active fragment slides its left edge to the right, just short of being completely offscreen. The vertically scrolling list is just an AdapterView, so it is possible to implement conditionally displayed items with different layouts, states, and even badges. (Below, our drawers as seen in mobile Safari, iPhone, iPad, and two Jelly Bean views, one which shows our Free Trial Membership banner.)

Based on our Android work, we went back and reworked our iPhone and mobile web navigation, implementing the sliding drawer across all of our mobile products. This is one case where cross-platform interaction consistency makes sense, but it’s the exception, not the rule.

4. When should we notify users of events in-app?
The HowAboutWe Dating app relies on numerous Status Bar Notifications for asynchronous messaging to the user. Some of these are generated by the application itself, and others are server push notifications powered by Google Cloud Messaging (GCM).

With the introduction of rich notifications, status bar notifications became much more visually appealing and powerful. Now more information can now be conveyed to the user via notifications along with additional options for taking action. (Below, notifications as they appear in our Android apps. At left, a new message in Jelly Bean; a successful upload; pending upload; Gingerbread notifications; and a failed upload.)

HowAboutWe uses notifications in Android for processes it might not in iOS. When a user uploads a new profile photo, for example, this requires transferring a non-trivial amount of data over the network. Instead of blocking the Android app’s UI with a loading dialog to communicate the status of the upload, a series of notifications is used to convey this information.

When the upload is started, the application generates a status bar notification to let the user know the upload is in progress. The network data transfer itself is processed on a background thread, so while the upload is pending, the user can continue to interact with the application.

Then, once the upload is complete, the application fires a second notification to let the user know the upload is complete. If for some reason the upload failed (say, a network error) a failure notification is shown instead. If the upload pending notification is still showing in the status bar, this notification is updated. The point is that the user never sees both pending and success notifications at the same time.

When the user receives a new message, a push notification is sent from using Google Cloud Messenger to notify the user. Rather than showing the classic “[USER] sent you a new message” text in the notification, using BigTextStyle for expandable rich notifications (on Jelly Bean devices), the user can actually read the full text of the message right in the notification. Also the profile photo of the user who sent the message is shown as the icon. Using the rich notification format (on ICS and Jelly Bean devices), we can even display a clipped version of the actual photo that was uploaded. Using the NotificationCompat.Builder class in the Support Library, these notifications gracefully degrade on older devices.

5. Which developer environment should we use?
Engineers thrive on good tools that save them time and help them write better code. Over the years, engineers have built vast integrated development environments, or IDEs, that allow other developers to dive right into high level implementation without needing to lay the groundwork. Instead, a few clicks and keystrokes allow you to compile, deploy, and commit your work back to version control. Before these lovely IDEs, programmers had to manually compile source files into object files, link them together, and ensure that all of their library paths were correct; writing a good, flexible Make script is a non-trivial undertaking. Further, IDEs can now inspect our code, optimize it, and refactor it–usually better, faster, and with fewer mistakes than our human hands.

In this section, we will attempt to compare the two most popular Java IDEs for Android development: Eclipse and IntelliJ. We will also include a supplementary comparison with Xcode, the official IDE for iOS development. We’ll focus on the following areas:

Text editing facility/UI operability

  • Keymapping: how customizable is everything?
  • Window management/manipulation: how easy is it to toggle between different tool views, and can you do it using the keyboard?

Code manipulation

  • Introspection: how well does the IDE examine your code and alert you to optimizations, improvements, and unused items?
  • Refactoring: what kind of refactoring operations are available and how powerful are they?

Version control integration

  • Source control manipulation: what kind of operations can you do from within the IDE, and what is the UI experience around it?
  • Interleaved command line use: if you switch branches on the commandline, does the IDE choke or does it keep up?

Eclipse
The first IDE to be officially supported by Google for the AOSP was Eclipse. Eclipse by itself does not come with Android support out of the box; it is added via Google’s Android Developer Tools plug-in. Previously, this was a separate installation, but Eclipse and the ADT plug-in are now available on the Android Developer website as a bundle.

The layout of Eclipse, IntelliJ, and Xcode is very similar; collapsible, resizeable tool panes on the left, bottom, and right edges of the application window with the editor window in the center. In Eclipse, these tool panes can be anchored to nearly all edges of the screen, can be minimized and can be popped out of the UI into separate windows. They can be summoned with a keystroke if they are not currently shown, but they cannot be hidden this way–you’ll need to reach for the mouse.

Introspection is quite powerful; it will warn you of unused variables and missing imports at the source level via a red (error) or yellow (warning) squiggly underline. Hovering the mouse over the offending token will show the Quick-Fix menu. The Quick-Fix menu offers helpful solutions to simple errors, and sometimes it suggests improvements or offers to do things like generate getters and setters for private variables. It is also accessible with a handy keystroke (⌘1). This is incredibly convenient–you can go straight from writing code to fixing it, without reaching for the mouse and reorienting your eyes to find the mouse pointer. (Below, the Eclipse Quickfix menu at left and refactoring menu at right.)

This, and countless other small opportunities for seamless operations can truly add up to extended periods of uninterrupted concentration.

Refactoring features of Eclipse are varied and are well-implemented. Changing method signatures, promoting local variables to member variables, extracting blocks of code into methods–all of these are easy to do. These functions can be accessed using the secondary mouse button menu.

These refactoring features are incredibly powerful and can save lots of time, but more importantly, can truly prevent mistakes when changes ripple across multiple files.

As far as version control integration, Eclipse comes with nothing out of the box–like the Android support, it requires a plug-in that is easy to find. There are several plug-ins available for git, Subversion, and probably anything else you’d want to use.

IntelliJ
Beginning with version 9, the JetBrains’ IntelliJ IDE added out-of-the-box support for Android. As of version 10, it became available in the free Community Edition version of IntelliJ, which opened it up for much more widespread use. The layout of this IDE is very similar to Eclipse w/tool panes on the bottom, left, and right edges of the IDE and the editor in the center. Also like Eclipse, these panels can be summoned with a keystroke, but unlike Eclipse, they can be hidden with the same keystroke, allowing fast toggling of tool panes exactly when you need them. This is incredibly useful in the contexts of quickly needing to browse the project hierarchy, checking to see which files have been modified since the last commit, or hiding and showing the console window, for example. It effortlessly surfaces information in a clear, concise manner and doesn’t make the user pay for it when switching back to coding. (Below, the IntelliJ commit view at left, and the IntelliJ changes pane at right.)

Like Eclipse, IntelliJ’s introspection features are thorough. It alerts the user to unused variables and unused code, but instead of using a single callout that signifies all generic warnings, it alerts the user to unused variables by subtle syntax coloring hints. Unused variables and functions are dimmed a darker shade, and they are never colored this way for any other reason–other more complex warnings are underlined and typically require manual identification.  Such informative visual cues are effective and non-interruptive. Yellow underlined items in IntelliJ are not always warnings–occasionally they are simple optimizations and quick wins. Sometimes it will point out that a member variable can become a local variable, or that a boolean expression is more complicated than it needs to be. This is great, as it constantly enforces good style and better code. Nearly all of these features can be quickly activated via IntelliJ’s Show Intention Actions feature, very similar to Eclipse’s Quick-Fix menu as described above–also bound to a handy keystroke.

IntelliJ’s refactor menu looks almost identical to Eclipse’s, though IntelliJ’s seems to be more of a superset. More features doesn’t always necessarily mean better, but it does offer a few things that Eclipse doesn’t.

Out of the box, IntelliJ offers VCS support for Git, Mercurial, Subversion, and CVS. You can even import projects directly from a repository URL, often without very much additional fiddling. This is by no means impossible in Eclipse, but it is incredibly convenient that it requires no extra plug-ins or components. First-party support for these features offers another level of comfort that just doesn’t come with third-party plug-ins. Mentioned earlier, the Changes pane in IntelliJ shows all changes made on all repository files since the last commit. In practice, this can be a priceless asset. After an hour of work, if you realize you are on the wrong branch and need to switch to another one that will require an ugly rebase–no problem! Shelve all, some, or parts of some of your changes to a changelist, do what you need to do on the command line, come back to IntelliJ and reapply as desired. Changing branches on the command line between trips back and forth to the IDE never produces any error-like dialogs asking if files need to be refreshed–they are refreshed automatically. The currently checked out branch is also always visible in the status bar.

All in all, raw code editing features across the three IDEs are similar. Each powerfully supports the user to quickly write clean code that is easy to change and reorganize. The experiences across the IDEs vary, though. Eclipse and IntelliJ have almost the same layout and featureset, yet these features are considerably easier to discover and are better implemented in IntelliJ. The overall look and feel of IntelliJ is more streamlined, more informative, and more responsive. Eclipse’s use patterns and appearance feel dated in comparison. When minimizing certain tool panes in Eclipse, sometimes it’s not obvious where they went or how to retrieve them. When popping windows out of the main window in Eclipse, they behave normally when dragged alone–but then dragging the main window causes the popped out windows to move along with it. It’s less than cute. In contrast, IntelliJ’s tool panes are all clearly labeled, cleverly placed, and easily toggleable. IntelliJ offers tremendous assistance and intervention without becoming intrusive. 

Make no mistake: Eclipse is far from unusable; however, it definitely hasn’t aged well, considering IntelliJ has been around for just as long. For Android, IntelliJ is a much smoother, more streamlined experience with a shallower learning curve. It feels like a modern piece of software, as software for making software should.

Xcode 4
Without delving into too many differences between iOS and Android implementation, we wanted to briefly discuss how the two most widely used Android IDEs compare, from an experience perspective, to Xcode. Once again, the same kind of overall layout is present here: central editor windows with collapsible tool panes on the outer edges. Like IntelliJ, these panels are toggleable with convenient keystrokes, but, as an added bonus, they sweep in and out of view with eye-pleasing, eased animations. Not required, but definitely neat.

Introspection in Xcode is definitely thorough, but it needs to be triggered, either from a clean, a compilation cycle, or with a pass of the static analyzer. In other words, not all errors and warnings are detected at source-level, many of them are only ever reported at compile time, which is more of a result of the platform architecture rather than the IDE. That said, the static analyzer is incredibly informative and graphical–it will draw arrows procedurally through code in order to illustrate where errors originate, and it explains how and why with associated textual cues.

Refactoring features in Xcode are comparatively limited. Automatically changing method signatures is not possible, only method renaming can be done. Blocks of code can be extracted into new functions or methods, but not into external protocols or categories. Getter/setter generation is possible through the Encapsulate option, but is not immediately useful since this can generally be achieved more concisely using properties. (Below top, the Xcode static analyzer; below left, the Xcode commit view; below right the Xcode refactor menu.)

Version Control Integration via Git or Subversion is thoroughly supported out of the box. As is possible in IntelliJ, it is possible to import projects directly from a repository URL, and repository creation is possible as well. For the same reasons as discussed before, this is immensely powerful. There are facilities for comparing changes and performing selective, detailed commits to specific branches.

6. Should our app be backwards compatible?
According to the current distribution graph, as of December 5, 2012, the majority of Android devices are still running Gingerbread (50.8%). A non-trivial number of devices are still running Froyo (10.3%). And roughly only one third of devices are running Honeycomb or newer versions (35.8%) of the operating system.

At first glance as an Android developer it might be tempting to decide to only use features available in all platform versions you will support. This is not a very good approach. To quote Mark Murphy, in his book The Busy Coder’s Guide to Android Development (v4.2):

When building HowAboutWe Dating for Android, we knew that we wanted to take advantage of recent advancements in the platform including fragments, action bar, rich notifications, and the Holo theme. Fortunately there are open source tools and strategies we found to help us deliver a modern and rich experience to users with the latest versions of the the platform, yet still provide a gracefully degraded experience to the rest of users and devices.

Action bar
The Support Library allows many platform features introduced in Honeycomb and later to be used on earlier versions of Android. However the Support Library is just a minimal set of APIs and only gets you so far. (Below, the action bar in Jelly Bean; the action bar in Gingerbread; and the action bar as it appears in the Jelly Bean inbox.)

Jake Wharton’s ActionBarSherlock project enables a fully functional backwards compatible version of the Action Bar and the Holo theme with very little work on the part of the developer. We leveraged both of these libraries in HowAboutWe Dating to provide a rich experience on all supported versions of Android. ActionBarSherlock even offers more flexibility than the system components in some instances, like allowing 3 action icons to be shown on smaller screens rather than the overflow menu.

Fragments
Early on we decided to take a fragment first approach to developing the app. The advantages of using fragments on a phone are readily apparent when using something like a ViewPager. For example, in the Messages section of the application, there are 3 fragments in a single activity using a ViewPager (Inbox, Sent, and Archive). Users can swipe or tap on the tab indicators to switch between the various fragments.

Even when only one fragment is active at a time, we still decided to implement the majority of functionality using fragments, to take advantage of the fragment lifecycle, APIs, and to ease the transition to tablets in the future. Most of our activities ended up as simple wrappers for the fragments they contained. On most screens, the activity handles high level functionality such as the Action Bar, broadcasts, and result intents, whereas the fragment handles the layout, user inputs, and basically everything else.

Custom back-ports
Sometimes even the tools available don’t give you everything you want. For example, in the sign up flow, we wanted to implement smart and stylish number pickers for birthdate and age preferences. While the DatePicker widget has existed since API level 1 (Base), the standalone NumberPicker widget has only existed since API level 11 (Honeycomb). (Below, the number pickers in Jelly Bean and Gingerbread, respectively.)

To build an age range picker in the same style as the date picker on Gingerbread and Froyo required implementing a custom backport of this component. (You can see both versions above.) Fortunately the NumberPicker widget is available as an internal component on earlier versions of the platform. After porting this widget from the Android source code into our project, all that was left was creating a wrapper class to use the correct implementation based on the current version of Android running on the device. See a code sample hosted on Github here.

7. How do we test our code?
Automated testing on Android is still not as simple as one might hope. Several solutions come bundled with the SDK including the Android Testing Framework, Monkey Runner, and JUnit. However the version of JUnit that comes with the Android SDK is JUnit 3. JUnit 4 can be integrated separately for unit testing but is not compatible with Instrumentation. Finally, there is Robolectric, an open source tool developed by Pivotal Labs that allows you to unit test Android code in the JVM.

There are also a number of testing services that have cropped up like TestDroid, AppThwak, and Apkudo. And of course there is good old-fashioned manual device testing. Each of these solutions has its own costs (time and/or money).

When building HowAboutWe Dating, we knew that we want to take a test-driven approach. The benefits of Test-Driven Development (TDD) are well documented by industry leaders like Kent Beck, Uncle Bob, and Michael Feathers, who we’ll quote below.

The Android Testing Framework is well designed for integration tests that run on an emulator or device. Automated tests are written in a separate test project that runs in the same process as your application. Using instrumentation, activities, and services can be tested running in a real environment.

However because this method requires you to compile, dex, and deploy TWO applications onto an emulator or device this is prohibitively slow for test-driven development. And as we all know, when tests are slow, the tendency is not to run them.

Pure JUnit, while fast, has the limitation of not being able to test any code that loads a class from the Android SDK. All business logic must be extracted into POJOs that are then invoked by the activity or service. While noble in principle, this quickly leads to cumbersome architecture. And you are still unable to test any logic that is linked to the lifecycle of Android components such as an Activity or Fragment.

Robolectric, however, provides the best of both worlds. Using a proxy for the Android SDK, unit tests can be run in the JVM without deploying to an emulator or device, and still invoke Android specific code. However, Robolectric is only as good as its coverage of the Android framework. But since it is open source, developers are encouraged to contribute to the project if you run into a part of the framework that does not yet have a proxy implemented.

With extensive unit test coverage, we are able to implement new features and refactor the code base with confidence, since ideally any regressions will be caught by the existing tests. This also gives us a high degree of confidence in the business logic that controls the application.

Beyond unit testing to cover our logic, to weed out issues related to differences between devices and OS versions we relied heavily on manual testing. With a big device library, we are able to test the final product on a representative array of devices to root out issues related screen sizes, densities, manufacturers, and OS versions. While this can seem daunting, thanks to our unit tests very few issues related to core logic are found at this stage which greatly reduces manual testing time.

While local builds work well for development phase, to ensure a high degree of consistency at the QA and release phases of the project we rely on a robust Continuous Integration (CI) environment. (For more on setting up your own continuous integration environment, check out this guide.)

QA and release versions of the app are built using Apache Maven and the Android Maven Plugin running on Jenkins. Dependencies and artifacts are stored on an internal repository server using Sonatype Nexus.

When a new commit is pushed to GitHub, our build server pulls the latest code from master. Using Maven, it compiles all the classes using the dependencies stored in our internal Nexus repository. All Robolectric unit tests are then run against the compiled classes.

If all unit tests pass, Jenkins then packages two versions of each build. First, a debug version is created that is configured for internal testing against our staging or production environment. Second, a release version is produced that is configured for upload to Google Play. Finally, both debug and release builds are archived in Sonatype Nexus for future reference.

This process ensures a high degree of consistency and reliability in builds that go to QA and/or are uploaded to Google Play and reduces the chance of issues introduced due to anomalies in the development environment or forgetting to run the tests.

Conclusion
The mobile game is rapidly moving out of inning one via exponential smartphone and tablet penetration curves (particularly outside the US); rapid innovation in mobile app design; smarter and more seamless monetization systems; infrastructural improvements to support performance; the burgeoning of a genuine advertising opportunity; growing development communities; and increasing mass addiction to our phones.

Alongside these changes, the design and engineering communities have built increasingly sophisticated frameworks and tools to support rapid app development. And yet, the literature about these frameworks and tools–particularly on Android–tends to be scattered and incomplete. We hope the development of the HowAboutWe Dating app as a case study will serve as a remedy for intrepid developers moving from iOS to Android.

Source:http://www.fastcompany.com/3002577/7-key-questions-ask-when-taking-your-app-ios-android

Did you like this? Share it:

Code signing: Stamp of approval for Android and iOS apps

An application security technique known as code signing is gaining importance as the Apple and Android mobile distribution centers require developers to provide the apps they write with a stamp of approval.

Code signing indicates that "you know where the code came from and it hasn’t been corrupted," said August Detlefsen, a security consultant for AppSec Consulting, in San Jose CA.

"The purpose is to basically guarantee that when you get some code, you know who it’s from," said Frank Kim, principal of security consultancy ThinkSec and curriculum lead for application security, SANS. "It’s to give you some level of trust."

Mobile application distributors use code signatures to help prevent malicious code from being distributed among mobile devices. "Both iOS and Android enforce the fact that your code must be signed in order to distribute it through the App Store or Google Play Store, so in order to get your software out there, you must sign it so that at least the identity of the person who created the code is verified," Detlefsen said.

Apple goes a step further and adds its signature to the applications distributed via its App Store. Before any code runs on an iOS device — assuming it hasn’t been jailbroken — the device verifies the signatures. This helps ensure the code has not been modified.

Developers who submit code for distribution via Apple’s App Store don’t have to be concerned with the details of code signing. "When I register for the iOS development program, it’s pretty straightforward," Kim said. "Apple makes the process as seamless as possible."

In other scenarios, the process of code signing is a bit more involved. "If you’re developing other types of software, server-side apps, or those distributed to enterprise customers in a different way, then it’s more cumbersome because the infrastructure is not there," Kim said.

Code is signed using public key cryptography. The process begins with the generation of a cryptographic hash. This is done by running the source code or compiled executable through a one-way function that calculates a checksum based on the bits in the code, Detlefsen explained. The resulting cryptographic hash is unique and non-reversible. The hash is sent through another cryptographic function along with a unique key known only to the user, resulting in a signature. It is a short alphanumeric string that is associated with the code. A public key, associated with the private key but freely sharable, can be used to verify the code is signed with the private key by running the signature and the corresponding public key though a signature verification function.

Public and private keys can be generated at no cost using one of the many key generator tools that can be found online, Detlefsen said. However, these keys do not offer verification that you are who you say you are. After all, Detlefsen pointed out, "Just because the code is signed doesn’t mean that the [developer of that code] knows what they’re doing."

An alternative is to purchase keys from a certificate authority, like VeriSign or DigiCert. These companies validate the identities of their customers. Information such as the signer’s name and organization is included with the code signature, and can be verified with the certificate authority.

There are no risks involved with the code signing process itself. However, the private key must be kept private. If an attacker were to obtain the private key, he could modify the code and sign it with the private key, leading people to believe the code came from a trusted source when in fact it did not.

While developers benefit from signing their own code, they also benefit from the signatures on the code they use. "A lot of developers use third-party code and open source libraries. If you’re building significant apps that require security, you should also check the authenticity of the code you’re using," Detlefsen said. An attacker could insert malicious code into an open source library. "Code signing provides one way of knowing that the code you’re downloading is verified to be the original and hasn’t been tainted in some way," he said. "Before you run it, verify the signature."

But not all code is signed in the first place. "Code signing is becoming more well-known and practiced because these distribution centers are requiring it. But as far as code you download over the Internet, or let’s say there’s an applet in your website or a flash app on a website, you might not know where it came from or whether it was something the original developers put there," Detlefsen said.

Source: http://searchsoftwarequality.techtarget.com/news/2240176128/Code-signing-Stamp-of-approval-for-Android-and-iOS-apps

Did you like this? Share it:

iPhone 5S/iPhone 6 Outer Shell Pictures Leaked: Real Or Fake?

Y2W)KPS3Y53OPSET)8K8}OR

While the latest sixth-generation iPhone 5 which released in September this year is still selling like hot cakes, recent rumors indicate that Apple has started making the next-generation of the iPhone a.k.a iPhone 5S or iPhone 6. Leaked images point towards an outer shell of the purported iPhone 5S/6.

Many tech experts are of the opinion that Apple will launch the next-generation iPhone in mid-2013, and that the trial manufacturing of 50,000 to 100,000 units of the smartphone has already begun.

"From the background, it seems that the pictures were taken at the assembly line of an operation stage. The photographer has showed the front and rear side of the housing, which looks very similar to the iPhone 5. However, the reason why we say it is a suspected iPhone 5s rear housing is that the specific information below the logo, which are replaced by "X". Usually, the parts with "X" stand for test prototype," reported iPhone5Parts.net.

iPhone5parts.net claims that they found some changes to the outer shell of the leaked images of the iPhone 5 when compared to the iPhone 5S. The Web site reports that per the leaked images, the iPhone 5S has two less screw holes on the left side which are used to fasten the LCD.

Furthermore, the position of three screw holes (used to fasten the logic board) has been removed.

The origin of the images is unknown, which means that it may be possible that the leaked image is of an old iPhone 5 prototype design that was discarded in favor of the design that was ultimately used. Also the image could also be a fake. However, the possibility of the leaked image being of the iPhone 5S cannot be ruled out as well.

The rumors of the next-generation iPhone have already begun and only Apple will know what the next iteration of the iPhone will look like and what will be the hardware built.

Till the next iPhone is launched, one can only glean information from the leaks and rumors for one of the most wanted devices in the smartphone industry.

Source:http://www.mobilenapps.com/articles/5450/20121207/iphone-5s-6-outer-shell-pictures-leaked.htm

Did you like this? Share it:

Apple Releases Guide to iOS Security

For years, mobile app security was essentially an afterthought. This was not only true for consumers, but also for development shops. Recently, it’s become quite clear that something had to be done to combat the rising tide of mobile malware, viruses and other threats.

Last week, Apple took a major step in the right direction by releasing A Guide to iOS Security. This 20-page document takes a fairly in-depth look at the iOS system architecture, encryption & data protection, network security, devices access and other areas.

Testers and developers would be wise to read the entire document, but here is a good summary from the guide’s conclusion:

Each component of the iOS security platform, from hardware to encryption to device access, provides organizations with the resources they need to build enterprise-grade security solutions. The sum of these parts gives iOS its industry-leading security features, without making the device difficult or cumbersome to use.

Apple uses this security infrastructure throughout iOS and the iOS apps ecosystem. Hardware-based storage encryption provides instant remote wipe capabilities when a device is lost, and ensures that users can completely remove all corporate and personal information when a device is sold or transferred to another owner. For the collection of diagnostic information, unique identifiers are created to identify a device anonymously.

Safari offers safe browsing with its support for OCSP, EV certificates, and certificate verification warnings. Mail leverages certificates for authenticated and encrypted email by supporting S/MIME. iMessage and FaceTime provide client-to-client encryption as well.

The combination of required code signing, sandboxing, and entitlements in apps provides solid protection against viruses, malware, and other exploits that compromise the security of other platforms. The App Store submission process works to further protect users from these risks by reviewing every app before it’s made available for sale.

Businesses are encouraged to review their IT and security policies to ensure they are taking full advantage of the layers of security technology and features offered by the iOS platform.

Apple maintains a dedicated security team to support all Apple products. The team provides security auditing and testing for products under development as well as released products. The Apple team also provides security tools and training, and actively monitors for reports of new security issues and threats. Apple is a member of the Forum of Incident Response and Security Teams (FIRST). For information about reporting issues to Apple and subscribing to security notifications, go to apple.com/support/security.

Apple is committed to incorporating proven encryption methods and creating modern mobile-centric privacy and security technologies to ensure that iOS devices can be used with confidence in any personal or corporate environment.

Source:

http://www.mobileapptesting.com/apple-releases-guide-to-ios-security/2012/06/

Did you like this? Share it:

The secrets to making money with mobile apps

A couple years ago, it was clear a Gold Rush mentality was brewing as the iPhone proved that people really, really wanted mobile apps. Lots of developers jumped in to claim their fortune, as did many students and regular folks lured by the promise of easy money through cookie-cutter apps created for them by forms-based websites. The Gold Rush fever has cooled, but not the desire for mobile apps, nor have the opportunities for real developers to make real money from mobile.

Forrester Research estimates that $17.5 billion worth of mobile apps will be sold this year across all platforms. Subtracting the cut that Apple, Google, and others get for placement in their app stores, that’s at least $13 billion for developers to pocket. But how to ensure you get the biggest slice of the pie? Ilya Laurs, founder of the app store GetJar, believes he knows the answer to that key question, based on analyzing the sales and revenues of thousands of mobile apps.

Laurs presented his analysis recently at the CIO Global Forum, an invitation-only, off-the-record thought leadership event for CIOs. And he’s agreed to share it with you. Before I get into the details, note that the vast majority of apps analyzed are consumer apps, so sales through an enterprise app store, such as the one Apple provides for employee app distribution, may not fit these patterns. Also, Laurs could not analyze Apple App Store sales data, but believes from anecdotal evidence that the basic model for making money "generally holds true" for iOS apps as it is for apps on other platforms.

Laurs’ analysis boils down to what he calls the user engagement model. In a nutshell, it means what you charge for an app should be based largely on how users engage with it.

For example, if people use your apps just a few times, an ad-supported model makes no sense, as you’ll earn just pennies per user. Better to charge 99 cents or $3.99 or whatever up front. Even though sales at the paid price will be a fraction of the free, ad-supported version, the total revenues are likely to be larger.

Conversely, if the user engagement is expected to be high, such as for a news, sports scores, social feeds, or other information-stream-oriented app, the advertising model makes much more sense. You’ll make more money from the many more impressions — sales-speak for the ads actually presented to app users — over the app’s lifetime even at a few cents per impression than if you charged a one-time up-front fee. Just beware, Laurs notes, that it’s often difficult to get paid by the ad networks.

Which begs the question: What about high-engagement apps that aren’t about information streams, where ads would be a turnoff? I’m talking games such as Angry Birds Space and Draw Something. The secret there, Laurs says, is to combine a relatively low up-front price (perhaps 99 cents to $4.99) with app purchases for virtual goods (such as powers and hints in games) and additional functions (such as bookmarking of your favorite teams for a sports app or ad removal to convert a free trial app to a paid one). Another advantage of in-app purchases is that billing is usually easy, either through the app store’s own system or through an established provider such as PayPal that users likely already have a relationship with

Then there are highly useful apps that don’t really support the notion of an in-app purchase or advertising. Those should cost more because they are more valuable. Examples in the iOS world are Quickoffice, iPhoto, Keynote, and GoodReader.

In some cases, a subscription model makes sense. Certainly, for a high-quality magazine like The Economist, which doesn’t repeat the same news everyone else has, a subscription is worth the reader’s money. Outside of media, I suspect the subscription model is a harder sell, though we’ll certainly see it with services such as the CloudOn Office virtual environment (currently offered for free as a teaser). We also see it with Quickoffice Connect, an attempt to get people to subscribe to the Quickoffice Office-editing suite rather than buying it just one time. However, Quickoffice Connect is a cautionary tale, as the subscription offering is a poor product that will hinder Quickoffice’s future attempts to convert users to ongoing payments — the same issue we see with Adobe’s attempt to convert its Creative Suite users into subscribers for a product that hasn’t justified its frequent upgrades for some time.

Laurs has created what he calls a user engagement model representing this app pricing strategy, as shown below.

Source:

http://www.javaworld.com/javaworld/jw-05-2012/120522-making-money-with-mobile.html?page=1

Did you like this? Share it: