3 ms·

This is interesting, why an iPhone application rather than something that can be perhaps web-based? I am working on (and by "working on" I mean, I created some

This is interesting, why an iPhone application rather than something that can be perhaps web-based? I am working on (and by "working on" I mean, I created some messy code 5 months ago and then abandoned it but cling to the dream that I may one day finish it) something similar, but wanted a web based UI - I have the same issue whether it is on a mobile client or at my desk. I want a twitter client that is smarter than a linear display of what's going on - and instead figures out the context of tweets (like replies and retweets) and intelligently gets me that context It looks like you are trying to solve that issue with replies, kudos to that.

hboon 18y ago
Being an iPhone application partially solves the selling part of the equation. You still need to market and have a good product, but sales and delivery is done for you, at the cost of 30% revenue and somewhat unpredictable release schedules. This particular functionality is actually a web service though. I built this running on a server and the iPhone client talks to the service. This provides some flexibility in terms of release schedules and most importantly works around the default Twitted rate limit. There is just no way a standalone Twitter thick client can do this without hitting the rate limit all the time, making the feature useless. It's interesting you mentioned retweets though, I haven't thought about that. One thing I'm looking into is the timestamp, @names and some herestics based on commonalities between tweets. I come from a search engine background, so mining text and relationship is always interesting to me. Why did you stop your work though?
- thwarted 18y ago
  Being an iPhone application partially solves the selling part of the equation. You still need to market and have a good product, but sales and delivery is done for you, at the cost of 30% revenue and somewhat unpredictable release schedules. Interesting. A web based application doesn't need delivery, but I wonder what kind of marketing you could get by leveraging the app store to market your product, but actually deploy it on the web. In other words, put a simple app on the app store that is merely a shortcut to spawning the web browser and taking you to your page. Could be free or paid, depending on how people respond to it. You could do more frequent updates too, without having to go through the app store, since it is web based. Do any apps do this currently?
  - hboon 18y ago
    If it's a web app, and you don't need/want the app store distribution, then you probably want to build it as a web app and market it as such. The app store itself is not much of a marketing tool unless you are already very popular. But then if it has no app store presence, how would you charge the user? I might build a few more features around the web service approach to take advantage of the rapid deployment benefit you mention, but probably not as a full blown web app. I don't know of any app doing the latter, but I'm not surprised if there is.

hboon 18y ago

Being an iPhone application partially solves the selling part of the equation. You still need to market and have a good product, but sales and delivery is done for you, at the cost of 30% revenue and somewhat unpredictable release schedules. This particular functionality is actually a web service though. I built this running on a server and the iPhone client talks to the service. This provides some flexibility in terms of release schedules and most importantly works around the default Twitted rate limit. There is just no way a standalone Twitter thick client can do this without hitting the rate limit all the time, making the feature useless. It's interesting you mentioned retweets though, I haven't thought about that. One thing I'm looking into is the timestamp, @names and some herestics based on commonalities between tweets. I come from a search engine background, so mining text and relationship is always interesting to me. Why did you stop your work though?

thwarted 18y ago
Being an iPhone application partially solves the selling part of the equation. You still need to market and have a good product, but sales and delivery is done for you, at the cost of 30% revenue and somewhat unpredictable release schedules. Interesting. A web based application doesn't need delivery, but I wonder what kind of marketing you could get by leveraging the app store to market your product, but actually deploy it on the web. In other words, put a simple app on the app store that is merely a shortcut to spawning the web browser and taking you to your page. Could be free or paid, depending on how people respond to it. You could do more frequent updates too, without having to go through the app store, since it is web based. Do any apps do this currently?
- hboon 18y ago
  If it's a web app, and you don't need/want the app store distribution, then you probably want to build it as a web app and market it as such. The app store itself is not much of a marketing tool unless you are already very popular. But then if it has no app store presence, how would you charge the user? I might build a few more features around the web service approach to take advantage of the rapid deployment benefit you mention, but probably not as a full blown web app. I don't know of any app doing the latter, but I'm not surprised if there is.