CanJS, the MVVM part of DoneJS, is currently coming up to its third major/breaking version. I think that’s a pretty good track record for us/Bitovi.
168 karma · joined May 13, 2009
CanJS, the MVVM part of DoneJS, is currently coming up to its third major/breaking version. I think that’s a pretty good track record for us/Bitovi.
Here’s a fun video talking about the same thing: https://www.youtube.com/watch?v=nQHBAdShgYI
“If you run to the press and trash us, it never helps.”
As someone who’s having a hard time gaining lots of new users for my service[1], I was really looking forward to some actual lessons in what’s worked. I checked out the Case Studies, but the content wasn’t anything new or particularly relevant to the scrappy startup situation. I think the most useful content on Grow/Hack right now is this post with actual lessons learned in growth hacking: https://news.ycombinator.com/item?id=4603640
[1] It would be remiss of me not to mention it: Iron Money https://ironmoney.com/
I would find it more likely that, even though (IIRC) the guy handling Instapaper’s support said he would pass it off to Marco, he simply didn’t see my suggestions or ever do anything with them.
Obviously this will vary from app to app, but I’m surprised that you have such a high number of users with an older version of iOS. Is that across all of your apps/games?
I’m not sure that we would. There are some great designers working on Android apps, but I don’t get the feeling that the UIs get the same critical eye, especially because there is less consistency throughout Android.
Marco should probably have the Archive box and the trash icon in the main list view instead of the trash icon that does both. However, I get the feeling that he doesn’t care as much about the polish of Instapaper as some people do. Last year I sent him an email with a list of adjustments to bring Instapaper in line with how iOS apps should behave (e.g. table view cells should fade out with the back-navigation transition instead of after it), but months later, most of the issues aren’t fixed. It’s the little things that really show polish and he doesn’t seem to be responsive to fixing the little things.
I wasn’t particularly thrilled that I was forced to drop support for iOS 3, but looking at the number of active users of my app[2] that were running the current version, I saw that none of them were on iOS 3. This was probably the right time for Apple to drop support for < iOS 4.3.
[1] I don’t have stats to back this up, but seeing that iPhone 3GS is the lowest hardware to support iOS 4.3, and they’ve sold way more devices since then than original iPhone and iPhone 3G, I think it’s fair to assume that the vast majority of iOS devices in use can run iOS 4.3 or later.
[1] https://ironmoney.com/ [2] https://ironmoney.com/ios/ [3] https://ironmoney.com/mac/
1. This makes sense and is what I thought would be my biggest hurdle. Thankfully, this has never really been an issue. A lot of people are surprisingly willing to trust their finances to a third-party they don’t know that well.
2. I agree, although I think it’s even more valuable to have professionals audit the source code. Both together is probably optimal for security.
3. I realize that, in the example you cite, it was helpful to have the source open, but in the case of a (usually) consumer product, I don’t think this argument holds much weight. Iron Money mainly targets young singles and couples who want their finances on the iOS devices and Macs, and having it be open-source rarely plays into the decision to purchase.
4. I agree. I don’t think Iron Money is really marketed as a closed-source library, but the point stands. In any case, I would probably open the source if the service was shut down.
Thanks for taking the time to write up your thoughts; they definitely provide food for thought.
When a “tab” is set up, the app can register with iOS to receive notifications when a user enters the geofenced region. As usual, the app will be suspended when you close it (i.e. not running), but when iOS detects you’ve entered the region, it’ll move the app into the background so it can run temporarily. In the case of Square, they might get a better GPS fix on you and tell their servers that you’re actually really close to where you have a tab open.
Even the evaluator determined that the layout of the home screen was too similar to iOS.
I run a 1.0a service provider and write clients against it. I’m thinking about wading through the current 2.0 draft, picking out the relevant parts to small startups with an API, and publishing a post about how to implement the sane parts of the 2.0 spec.
[As for everything else, I use email for all communication and don’t use Github, so everything stays in email or Things.]
In the same way that new companies should be an improvement to what is already offered by others, I think there is a lot to be said for learning the successes and failures of how other companies run before starting your own.
More info on restrictions: https://support.apple.com/kb/HT4213
I’m not quite sure what your security question is. Since the API and web app use different authentication schemes and have different endpoints, there is no risk of CSRF.
Apple already has a solution in place for this problem: the app review process. When Apple figures out how apps should integrate with Siri, I think they’ll have guidelines/rules for how apps should use the Siri APIs and they’ll be able to enforce those rules with the review process.
[1] https://www.stanford.edu/~mjockers/cgi-bin/drupal/node/25