toddfearn.com

Distributing ad-hoc releases of your iOS apps used to be a real pain.  However, recently we’ve been using a product called TestFlight (http://testflightapp.com) that’s made it a cake walk.

Here’s how it works:

1. Create a team of users.  All you need is a name and email address for each user.
   
   
   Testflight will send each member a link to the TestFlight iOS app.  When the member installs the app, the UID of the device is sent back to the Team manager.
2. The Team manager takes each device UID and adds them into the Provisioning Profile for the app.
3. Then simply generate an ad-hoc release (.ipa) and upload it to TestFlight.
4. Choose the team members that should receive the app and you’re done.

The primary pain this free service solves is the acquisition of UIDs from your testers.  If you’ve ever done this without TestFlight, you typically receive a bunch of invalid UIDs from your testers. 

And the management facility is nice, as long as you’re using Safari (I guess they’re using some HTML5 constructs that Firefox does not yet support).

This project was a lot more work than we had originally anticipated, especially on a part-time basis.  Many thanks to all to all that participated!

Check out the quick 2 minute video below.

So why a check-in app for stocks? I believe the concept of sharing stock picks and market ideas with followers via a social network is very cool. 

Using Finster you can quickly express your views on a stock, option, index or just about any security listed on an exchange.

I just need Jim Cramer to start using it and we’re all set.  :)

Download it and try it out, available in the App Store.  Give me some feedback.

I just took a quick gander at this video released from TD Ameritrade where they are claiming that they will see more mobile app based access to their systems than PC based access by 2013.

With traders increasingly looking for customized mobile solutions, TD Ameritrade recently rolled out apps for the iPad, iPhone, BlackBerry, Windows phone and Android, and has seen its mobile trading increase by 125 percent over the last year.

I don’t think we’re going to see this on the institutional side anytime soon, but the momentum continues to shift away from desktops.

Apparently, according to a recent survey, 54% of Bankers Call Creating Mobile Corporate Banking Services A High Priority.  

Yet their primary concern is mobile device security.  Asked about the biggest barriers to growth in mobile corporate banking, 77% cited fraud and security concerns.

Having designed and led a team to build an iPhone/iPad app for a major wall street bank, I know first hand that this is a serious concern inside the firm.

Here are a few steps you can take:

1. Don’t store any sensitive information on the device.  Actually we don’t store anything at all, other than the login username, and this is only if the app user chooses to save this for ease of future login.  Citigroup reported a security flaw in it’s iPhone app in July 2010.  The problem: they were storing sensitive information on the device.


2. Check for a jailbroken device at startup.  When a device is jailbroken, you can gain full access (root access) to unlock all features of the said operating system, thereby removing limitations imposed by Apple.  This means a hacker can get at the apps and the data on the device.  They might even be able to decrypt your application binary and determine the logic, communication endpoints, and more. 


3. Ensure that all external communication is secure.  Use secure protocols when communicating with external bank systems (HTTPS, SSL, etc).  We actually implemented an additional redirection layer on top of this.


4. App timeout and/or closure upon exit.  In case a phone is left somewhere unlocked or let’s say without a password on the device, you want to make sure someone can’t just pickup the device and get to the app without providing credentials.  You can employ a timeout on the app, requiring login after let’s say 5 minutes of inactivity.  
   
   Apple also has an option in it’s build settings called “Application does not run in background”.  This is in the build plist file and if checked, when the home button is pressed the application will close completely, requiring a reload.  The default setting is unselected, meaning that the app stays in memory unless the device is rebooted.  In this case, you had better employ some kind of timeout period requiring credentials after timeout.


5. Hire an external vendor to perform a penetration test.  We hired a 3rd party security specialist firm to do this.  They tested all communication endpoint urls as well as the protocol and the actual device.  This is a relatively new area, so find a vendor that has experience with mobile device security.

I’m probably forgetting a few details, but these are the basics.