Category Archives: iOS

Jul 14
0

Solution Accelerators – iOS Updates

By on July 14, 2013 | iOS, Mobile App Development | No Comments

Earlier this month we launched v2.4.0 of our Fusion Mobile for iOS – the culmination of months of hard work, thousands of caffeinated beverages consumed, and the aggregate of tons of really great fixes and features for you to make your apps even better. And since then, we’ve pushed ahead in Beta even further to v2.4.16, which has even more great stuff!

• Ads – We’ve added official support for Google’s Admob. Just use the <GoogleAd> widget!
• Native Social – We’re now supporting the iOS-native sharing sheets for both Twitter and Facebook. No more need to manually authenticate and handle the posting yourself. Just use the <Social> widget!
• Save Snapshot – The new save-snapshot function of the <Layout> widget allows to you render whatever contents you have in a container as a static image file, which you can then manipulate like any other image!
• Aviary – Speaking of manipulating images, we’ve implemented native support for the Aviary SDK (www.aviary.com). This allows you to apply filters to images, opening up all sorts of hip possibilities for photo manipulation and making the proverbial rose-tinted glasses available for any photo your user takes. It’s built right into the <MediaPicker> widget! Add filters, stickers, text-overlays, borders – we could go on forever. Insta-who?
• Image Blur – In addition to saving snapshots of your layout containers, you can now apply a Gaussian blur to any <Image> widget. For anyone who has seen the demos of iOS 7 – you know this effect is in-play everywhere. Now you have the ability to use depth-of-field for your own clever purposes in your own apps!
• Connection Type – Do the data-availability blues got you down? We’ve added the [app:connection-type] shortcode to the platform, so that you can discern between when your users are on Wi-Fi, a mobile network, or no network at all!
• Multi-line Text Input – The new <MultiLineTextInput> gives you line-break abilities far beyond those of mortal men.
• Asynchronous Loading – Power-tune your app’s performance when loading large images or <Element> widgets! The load-asynchronously property allows you to defer loading of these items to a separate process, so your UI gets on-screen as soon as possible and your users stop holding their breath.
• Email Attachments – Need to send out some photos from within your app? The <Email> sheet now supports attachments! Send, send, send!
• Multi-finger Swipe Gestures – Capture two-, three-, or four-fingered swipes!

Feb 11
0

The Top 5 Challenges Supporting the Conventional Mobile SDK (and What We Are Doing About It)

By on February 11, 2013 | iOS, Mobile App Development, Mobile SDK | No Comments

Since we started focusing on providing Mobile SDK Management Services as a core offering, we have learned some lessons on just how difficult creating a world-class SDK can be.  Here are our top 5 Challenges for Supporting the conventional Mobile SDK:

  1. Building the SDK is hard and expensive work. It typically starts with an assessment of security requirements and the creation of the User Interface Design. Coding requires expensive development resources that you will probably need to be pulled from critical projects. Within the mobile ecosystem, these developers need to keep constantly abreast of changes in OS platforms. How many developers are required to build and effectively test the SDK? How about code maintenance? What happens when bugs are uncovered or the API is changed to reflect core system updates? How quickly can you deploy features to capitalize on new business opportunities?
  1. The cost of support. It takes a developer skill set to support developers and test the SDKs. A small enterprise needs a team to build, maintain, and provide the needed phone, email and chat support their publisher network demands.

             Even a small SDK Management team can be expensive:

FTE

Cost Per

Sub-Total
Mobile Developer

1.5

$110,000

$165,000
QA Engineer

0.5

$75,000

$37,500
Support

1

$55,000

$55,000
Community Manager

0.5

$75,000

$37,500

Annualized Labor

$295,000
  1. Creating a knowledge base. A good SDK needs online support. A portal site with an FAQ section, video tutorials, and documentation should be in place to guide the developer through use of the SDK. Just as with your API, you need to address onboarding new publishers and integration with Affiliate management systems.
  1. Performance Management. You will need good analytics and reporting to insure the SDK in performing well.  If your SDK creates a UI, you will need to use those tools to continually optimize the interface to create the best conversions.
  1. Perhaps the biggest challenge in supporting the SDK is the update distribution lifecycle. Even well managed companies with highly motivated publishers – companies like Google – find the half-life on SDK updates can be six months. First they need to inform the publisher of the update, then work their way into the publisher’s product development cycle. Developers build, test and submit the updated product to the app store.  Store approval alone can take several weeks. Lastly, the users need to update their individual devices.

It’s no small wonder that a typical service provider of scale will typically need to support several SDK versions simultaneously. The need to update the SDK because of bugs, critical business changes and external OS changes often happen before the last version has even been fully distributed. At the very least the service provider can expect to support two SDK versions at once. That may create challenges for the API, critical back end systems, and those that support them.


Because the core of the Red Foundry platform is basically a rendering engine we are in a unique position to create fully native components that allow for routine UI modifications without the need to recompile the binary. While this goes a long way to address the challenge of the SDK distribution lifecycle, we saw the benefit in addressing all the challenges that go along with syndicating your technology or content.

Our SDK Management Service  leverages Red Foundry’s expertise managing a large mobile developer community and provides an end to end solution, from SDK requirements gathering and multi-platform development all the way through supporting publishers using your SDK through a developer portal complete with  tutorials,  guides, knowledge bases, and monitored forums. Most importantly, we can work with our service partners to insure the SDK performs and remains updated as their business grows.

Jan 16
1

Top 5 Reasons you should have a mobile SDK

By on January 16, 2013 | Android, iOS, Mobile App Development, Mobile SDK | No Comments

The ability to distribute a service across mobile devices and applications is driving the explosion in mobile commerce and application design.

The API Services and Directory site ProgrammableWeb.com lists 7,000 Application Program Interfaces (API)s and adds more than 300 the list every month.  They’ve made the case that every company can and will have an API. The development of robust APIs has been instrumental to the explosive growth of companies like Google, Facebook and Twitter. The key motivation for investing in this technology is that it helps developers work with other companies to create tools that help improve engagement and conversions.

So if your service has an API, do you also need a mobile SDK? In short, the answer is “yes,” especially if mobile is strategic in your company’s growth. At Red Foundry we partner with a wide variety of service providers and they site the following top five reasons for creating a mobile SDK:

  1. Close more sales.  The biggest reason to create a mobile SDK is to help sales and business development staffs close key deals faster. The SDK do this by helping move the process of integrating services along more quickly.
  2. Speed up deployment. Time is a critical cost factor because the integration services are performed by mobile engineers with a highly valued skill sets. Having an SDK can help them simplify their projects and enable integration of APIs that require complex use cases that are complemented by standard on-client processing for mobile devices. A SDK greatly simplifies this integration effort.
  3. Increase security. Security may be a critical issue. In the case of large ad networks, SDKs are often required in order to reduce programmatic fraud. SDKs can be used to encrypt portions of the user interface (UI) to secure data quality. Mobile payments processing requires PCI compliance and some platforms may have specific requirements for storing passwords, etc. A SDK can help provide that needed security.
  4. Reduce bad code & ensure best practices Developers are rarely perfect. Even the best can make mistakes. Errors in how data is passed to back end services can cause critical issues and delays that impact the entire business. Inefficient code by a single developer can take down services for across the enterprise. The SDK can go a long way to reducing bad or inefficient code and its impact on critical systems. The right SDK can further insure the right business rules and practices are in place across their entire publisher network.
  5. Control over your brand. Control over your brand with the UI of the publisher’s app may be critical to your business.  Developers aren’t designers; an SDK will allow you to lock down critical portions of the interface while retaining analytics needed to see how the users interact with your service within the publisher’s application.

So SDKs help publishers and the developers that work for them integrate with the service providers APIs more quickly. That saves time, saves money, and helps close more deals. They make life simpler for the developer, insure best practices, and keep critical systems secure. So why doesn’t every service provider with an API also offer a SDK?

Bitnami