FutureText Lite - Submitted to Apple for Approval

[jbardi]

Well, I finally submitted my first App to the App Store, so looks like I have about 2 weeks to wait for approval. This is a paid App, and I have not seen any other Paid Nimblekit Apps, but I could be wrong. This is the Lite edition, so it will be selling for $0.99USD in the United States and Canadian stores only to start out with because it currently only contains support for Carriers in the US and Canada. The next release will have a built in update feature to allow full International Carrier support to be continually added on the fly.

After the Lite version is approved, I will be distributing promo codes to users on the forum here so that I can get feedback on any bugs I may have overlooked, and I will also finalize my work on the Pro edition which will sell for $2.99 - $3.99USD.

Here are some screenshots so you can get an idea of what the App does:
(Click the Images if there are scroll bars and they will disappear)

Screen1.jpg (45.63 KiB) Viewed 1094 times

Screen2.jpg (54.42 KiB) Viewed 1094 times

Screen3.jpg (66.95 KiB) Viewed 1096 times

[blazeman]

I like the concept. I wonder if they will say it duplicates the messaging function of the phone though.

Hopefully they will approve so we can see it in action!

What's the differences of the pro and lite versions?

[jbardi]

Well, there are 2 other Apps in the app store that do the same thing as Mine. One of them is on par with mine as far as having a Lite and Pro version, while the other one is a very basic one page app, but both of them have been in the App store for a while now, so Apple has no problem with this type of App.

The Lite version allows you to schedule a text message, but once it is sent to our servers and stored in our database to be sent at the specified date and time, you can not change it or cancel it. Once it is sent, it is sent.

The Pro version opens to a Table view that will show your currently scheduled text messages and allow you to edit or delete them anytime before their scheduled delivery date/time. For instance, if someone was angry over a recent breakup and decided to send their ex-girlfriend a nasty text message to be delivered on her birthday, then they reconciled, he could not stop that text from being delivered with the Lite version, but in the Pro version he could. This is a major undertaking over the Lite edition, so well worth the difference in price.

The Pro version will also receive future feature updates while the Lite edition is pretty much a final version that will only receive bug fixes. And, I will be giving away promo codes for the Pro version here on the forum as well.

[sunny]

looks really nice! and the idea is nice too
too bad only 2 countries are supported at the moment (and I'm not in either of them )

This is a paid App, and I have not seen any other Paid Nimblekit Apps

Mega Trivia: Back to the 80s also paid app.

[jbardi]

looks really nice! and the idea is nice too
too bad only 2 countries are supported at the moment (and I'm not in either of them )

I know, it was a semi rush on my part as the bulk of my coding time was in the functionality and I filled in the Carrier list as the last thing and I had some trouble verifying all of the International connection addresses for each carrier, so I threw in the ones I knew were definitely accurate for the US and Canada. The update for full International support will be released very soon after this first release is approved, so not to worry

Mega Trivia: Back to the 80s also paid app.

Oh, cool, I didn't know it was a paid app... thats how much I pay attention

[Andy Baird]

Nice clean design--I like it! :-)

Andy Baird

[jbardi]

Thanks Andy. This goes to show how easy it is to use iWebkit (or iUi) to achieve a fast, clean layout so you can spend more of your time focusing on the backend code and functionality.

I just got through posting about how too many people are requesting the Nimblekit team implement all kinds of interface objects (buttons, lists, checkboxes, etc) when nearly ALL interface objects, outside of those used for Navigation (NKNavigationController, NKTabBarController, NKToolBar) should always be implemented in HTML and CSS rather than as native Nimblekit objects.

I think the idea of Nimblekit is as a functional, light weight API to give Javascript developers access to native iPhone features, and not to recreate all of the iPhone Interface objects, otherwise it would be too bloated to include in every project. I think people learn more about design by creating and tweaking their interface with HTML and CSS then they do by simply including a line of code that does all the work for them.

Thanks again everyone for the encouraging words... having to code like crazy on my other Apps to keep my mind off of how slow time is going by. I want this approved like now

[sunny]

it's been 2 weeks, any news?

[bsoft]

really nice app!
Hope it will be good for.

Also, i like the button you used. How did you do them ?

[jbardi]

it's been 2 weeks, any news?

Yeah, I was rejected on the first attempt. Really pisses me off actually. They claim that my app allows people to send anonymous or spoofed text messages, which is very true, only because Apple will not allow us to directly access the phone number of the iPhone that is running the application so that I can hardcode their number as the sender. I guess because they think it is a privacy issue, and yet they give you direct access to the address book so you can grab the numbers of the iPhone owners friends and family and that is not a privacy issue?

Anyway, I am not pissed for the reasons they rejected it, except for the fact that there are 2 other applications on the App Store right now that do the EXACT SAME THING as mine and they were approved without a problem, and one of them just recently submitted an update which was also approved, even though both of them allow anonymous and spoofed text messages.

If they are going to hold one app to such high standards, they need to hold ALL of them to the same standards. The idea that one reviewer approves an app with these features while another reviewer thinks it is against Apple's policy and disapproves mine is ridiculous. But you can't tell Apple that... I tried writing the reviewer back and asking why I was rejected while the other two Apps were approved and he respond by telling me to go ask for code level support in the forums. What an Ass!

Well, I found the undocumented code for retrieving the phone number of the iPhone and set it so that the user could not change the phone number and then resubmitted the App.... but apparently it takes an additional 14 days on resubmission as you get no preferential treatment over new submissions. They will probably reject it again because I am using an undocumented API command.