5 ms·

Show HN: Taplytics, A/B testing on iOS without App Store updates

61 points by cdrux 13y ago

jkresner 13y ago
This is awesome. I've wanted optimizely for mobile forever.
ksar 13y ago
Congrats Cobi and team, this looks awesome!
jonathanehrlich 13y ago
Congrats Aaron and team. Great news.
w4 13y ago
This is great. I can already see using it for an app I'm working on to optimize the IAP dialog.
cclogg 13y ago
Looks cool! I have a somewhat related question for anyone who works on tools/frameworks (for iOS I guess)... is it a pain to deal with iOS versions, ARC/non-ARC, and anything else? I was reading the quick start guide here and I noticed it said iOS 6.0+, so I guess you just have to look at the market share and make a trade off as to how much you want to support? I've personally only worked on apps themselves, but I've always wondered if the people making Flurry, Tapjoy, etc have to go through hell getting their framework to work for every combo of Xcode and iOS out there lol.
- ryanhuff 13y ago
  From a developer perspective, one of things that Apple does very well is to move people to quickly adopt new versions of iOS. As of December, iOS 6+ covers over 95% of its user-base. http://appleinsider.com/articles/13/12/05/apple-pegs-ios-7-distribution-at-74-ios-6-at-22 http://appleinsider.com/articles/13/12/05/apple-pegs-ios-7-d...
- jonathannorris 13y ago
  Thanks for your interest! I'm one of the co-founders of Taplytics. Building for iOS in general has improved a lot. Apple has really cleaned up iOS and Xcode in the last two years, with ARC being a huge improvement for developers. Seeing that iOS 6+ is now 97.7% of devices (https://mixpanel.com/trends/#report/ios_7 https://mixpanel.com/trends/#report/ios_7), we feel that focusing on iOS 6+ is a safe bet going forward.
- michaelmior 13y ago
  I'm sure many others have far more experience than I do, but here's my thoughts. I think there's little value in dealing with non-ARC at this point. ARC has been supported since iOS 5, which is available for the 3GS and up. I no longer do app development full time, but as of last year, a very tiny percentage of our users were on iOS 5. Most of the new features in iOS 6 that would be used by libraries are developer conveniences and can be ignored with a bit more effort. (e.g. Auto Layout, UICollectionView) As far as different versions of Xcode, there's really no reason for developers not to use the latest in my experience, so targeting that is likely fine.
- Blahah 13y ago
  On AnkiMobile, whenever we find we want to use a feature or library that is much easier or only possible on later iOS versions, we review market share. We recently started retiring 4.3, and will soon retire 5. We already develop some new features only for iOS6+ devices, and simply decide at runtime whether they are to be used. It's not a huge pain, but it's a prominent feature of developing for devices that are frequently updated. We always use the latest XCode and the latest SDK. Often there are language features that greatly reduce development time, like the NSDictionary/NSArray literals for example. The only downside is that later XCode versions don't support low-iOS version simulators, so you have to test on-device only when supporting older devices. But this all helps justify to users when you stop supporting older devices.
tylermac1 13y ago
Very cool! Definitely will look into this for my future apps.
Brushfire 13y ago
Great stuff. $20? You should be charging 10x that.
- cdrux 13y ago
  Hey, thanks so much for checking us out. Our goal is to keep the platform affordable so developers like us could actually use it and grow with it.
  - Brushfire 13y ago
    Obviously you know your customers better than I do, but I bet you could keep the free plan, 2x-3x your middle plan, and 5x your upper plan and still service the same number of customers. The delta from $20 to $50 isn't going to break anyones bank, but I suspect the change in unit economics mean big things for your business/LTV.
morgante 13y ago
My question is how does a service like this not violate Apple's requirements? Isn't this a super easy back door around the App Store? Just submit a nice, simple app to Apple and inject offending modifications via Taplytics.
- jonathannorris 13y ago
  Testing on mobile is becoming more common as the platforms mature, and critical to the success to many mobile apps including: Facebook, LinkedIn, and Twitter. With Taplytics, because we use native iOS elements (no HTML wrappers), we are not modifying your packaged code just adjusting properties on the fly. All of your code still gets reviewed by Apple.
  - mrfrisby 13y ago
    How deep do those properties go? Can I run sophisticated tests which change data sources, layout, etc. Or is your app focussed for now on the more trivial things like colour and copy? And on the copy front, do you support multiple languages within a single experiment?
    - jonathannorris 13y ago
      We can change any native UIKit Class property using our sub-classes or categories. Currently, we are keeping it simple on the web interface to content and layout changes, but we also support more complex experiments like controlling view flows. Currently we have limited the interface to a single language, but multiple language support is built into the SDK/API and we will be publicly releasing it in the near future!
- baddox 13y ago
  I imagine that would depend on what exactly Taplytics allows (or at least encourages) you to change dynamically. While I suspect that Apple prohibits loading code remotely, I'm not sure if they would object to loading CTAs remotely any more than they would object to loading a news feed remotely.
michaelmior 13y ago
At my previous position we built our own A/B testing framework for iOS. There were a few hiccups, but overall it wasn't too complicated. One thing that was important for us was to be able to tie together stuff happening on the Web side of the product with tests running in the app. Curious if this is possible with Taplytics. Despite the DIY solution being relatively straightforward, given that they have a free plan, this seems like a much better way to get started.
- cdrux 13y ago
  Thanks for the comment. We agree that keeping your web presence in sync with your mobile product is critical. We have built Taplytics out as a big API engine with the goal of managing multiple platforms, iOS is just where we're starting.
trey_swann 13y ago
This is a great way to make your native mobile interface completely dynamic. Sure makes mobile A/B testing a whole lot easier. ‘No app store approvals’ is huge. This is cool. I'm a fan!
suyash 13y ago
The other day I saw a better demo of the same functionality by guys at Optimizely, it's in beta and coming out soon!
saurik 13y ago
I am interested in how this product compares with Apptimize (a company that happens to be backed by Y Combinator). http://apptimize.com/ http://apptimize.com/

61 points by cdrux 13y ago

jkresner 13y ago

This is awesome. I've wanted optimizely for mobile forever.

ksar 13y ago

Congrats Cobi and team, this looks awesome!

jonathanehrlich 13y ago

Congrats Aaron and team. Great news.

w4 13y ago

This is great. I can already see using it for an app I'm working on to optimize the IAP dialog.

cclogg 13y ago

Looks cool! I have a somewhat related question for anyone who works on tools/frameworks (for iOS I guess)... is it a pain to deal with iOS versions, ARC/non-ARC, and anything else? I was reading the quick start guide here and I noticed it said iOS 6.0+, so I guess you just have to look at the market share and make a trade off as to how much you want to support? I've personally only worked on apps themselves, but I've always wondered if the people making Flurry, Tapjoy, etc have to go through hell getting their framework to work for every combo of Xcode and iOS out there lol.

ryanhuff 13y ago
From a developer perspective, one of things that Apple does very well is to move people to quickly adopt new versions of iOS. As of December, iOS 6+ covers over 95% of its user-base. http://appleinsider.com/articles/13/12/05/apple-pegs-ios-7-distribution-at-74-ios-6-at-22 http://appleinsider.com/articles/13/12/05/apple-pegs-ios-7-d...
jonathannorris 13y ago
Thanks for your interest! I'm one of the co-founders of Taplytics. Building for iOS in general has improved a lot. Apple has really cleaned up iOS and Xcode in the last two years, with ARC being a huge improvement for developers. Seeing that iOS 6+ is now 97.7% of devices (https://mixpanel.com/trends/#report/ios_7 https://mixpanel.com/trends/#report/ios_7), we feel that focusing on iOS 6+ is a safe bet going forward.
michaelmior 13y ago
I'm sure many others have far more experience than I do, but here's my thoughts. I think there's little value in dealing with non-ARC at this point. ARC has been supported since iOS 5, which is available for the 3GS and up. I no longer do app development full time, but as of last year, a very tiny percentage of our users were on iOS 5. Most of the new features in iOS 6 that would be used by libraries are developer conveniences and can be ignored with a bit more effort. (e.g. Auto Layout, UICollectionView) As far as different versions of Xcode, there's really no reason for developers not to use the latest in my experience, so targeting that is likely fine.
Blahah 13y ago
On AnkiMobile, whenever we find we want to use a feature or library that is much easier or only possible on later iOS versions, we review market share. We recently started retiring 4.3, and will soon retire 5. We already develop some new features only for iOS6+ devices, and simply decide at runtime whether they are to be used. It's not a huge pain, but it's a prominent feature of developing for devices that are frequently updated. We always use the latest XCode and the latest SDK. Often there are language features that greatly reduce development time, like the NSDictionary/NSArray literals for example. The only downside is that later XCode versions don't support low-iOS version simulators, so you have to test on-device only when supporting older devices. But this all helps justify to users when you stop supporting older devices.

tylermac1 13y ago

Very cool! Definitely will look into this for my future apps.

Brushfire 13y ago

Great stuff. $20? You should be charging 10x that.

cdrux 13y ago
Hey, thanks so much for checking us out. Our goal is to keep the platform affordable so developers like us could actually use it and grow with it.
- Brushfire 13y ago
  Obviously you know your customers better than I do, but I bet you could keep the free plan, 2x-3x your middle plan, and 5x your upper plan and still service the same number of customers. The delta from $20 to $50 isn't going to break anyones bank, but I suspect the change in unit economics mean big things for your business/LTV.

morgante 13y ago

My question is how does a service like this not violate Apple's requirements? Isn't this a super easy back door around the App Store? Just submit a nice, simple app to Apple and inject offending modifications via Taplytics.

jonathannorris 13y ago
Testing on mobile is becoming more common as the platforms mature, and critical to the success to many mobile apps including: Facebook, LinkedIn, and Twitter. With Taplytics, because we use native iOS elements (no HTML wrappers), we are not modifying your packaged code just adjusting properties on the fly. All of your code still gets reviewed by Apple.
- mrfrisby 13y ago
  How deep do those properties go? Can I run sophisticated tests which change data sources, layout, etc. Or is your app focussed for now on the more trivial things like colour and copy? And on the copy front, do you support multiple languages within a single experiment?
  - jonathannorris 13y ago
    We can change any native UIKit Class property using our sub-classes or categories. Currently, we are keeping it simple on the web interface to content and layout changes, but we also support more complex experiments like controlling view flows. Currently we have limited the interface to a single language, but multiple language support is built into the SDK/API and we will be publicly releasing it in the near future!
baddox 13y ago
I imagine that would depend on what exactly Taplytics allows (or at least encourages) you to change dynamically. While I suspect that Apple prohibits loading code remotely, I'm not sure if they would object to loading CTAs remotely any more than they would object to loading a news feed remotely.

michaelmior 13y ago

At my previous position we built our own A/B testing framework for iOS. There were a few hiccups, but overall it wasn't too complicated. One thing that was important for us was to be able to tie together stuff happening on the Web side of the product with tests running in the app. Curious if this is possible with Taplytics. Despite the DIY solution being relatively straightforward, given that they have a free plan, this seems like a much better way to get started.

cdrux 13y ago
Thanks for the comment. We agree that keeping your web presence in sync with your mobile product is critical. We have built Taplytics out as a big API engine with the goal of managing multiple platforms, iOS is just where we're starting.

trey_swann 13y ago

This is a great way to make your native mobile interface completely dynamic. Sure makes mobile A/B testing a whole lot easier. ‘No app store approvals’ is huge. This is cool. I'm a fan!

suyash 13y ago

The other day I saw a better demo of the same functionality by guys at Optimizely, it's in beta and coming out soon!

saurik 13y ago

I am interested in how this product compares with Apptimize (a company that happens to be backed by Y Combinator). http://apptimize.com/ http://apptimize.com/