I want to integrate the iPhone sms like chat bubbles in my application. But when I read more about it I found that this will not be approved by the app store. Is this true? Cant we use chat bubbles in the application?
Here are some links which describes this.
http://www.iphonestalk.com/iphone-app-store-submission-rejectedbecause-of-chat-bubbles-angry-developer-speaks-out-5836/
Thank you
The article is over a year old.
There are hundreds, if not thousands of apps in the app store using chat bubble images that look identical to those used in the SMS app.
Some of those apps I use, some of them I created. I've never had a rejection based on the chat bubbles.
Based on the link, it sounds like it. Although I would review the full app store review guidelines here (Note: requires you to sign in as an Apple developer). When you think about it, it makes sense though. Apple has spent a lot of time designing a unique interface and if they have, in fact, trademarked/patented that style of displaying a two-way chat, there's no way they're going to let you use it.
To be honest with you, I think it's likely more complicated than "yes you can use chat bubbles" or "no you cannot use chat bubbles." There are probably some fairly specific guidelines that define what Apple has trademarked/protected and what they haven't, hence the suggestion to make them less shiny. Long and short of it is, if you application looks exactly like the iPhone SMS application, I don't see it fairing well in the review process.
Related
This is a simple question on a (probably) complicated topic.
I'm in the process of trying to build an app in which multiple users are invited into a session by a single user.
If they accept, I would like the session admin/host's device to control the views on the devices of all the users in that session.
I have searched high and low, Google, StackOverflow, Treehouse etc. but whenever I suggest multiple users or type the question as I have here I get responses that demonstrate how to make an app capable of supporting multiple users on one device, or similar.
The question is simply: is what I want to do possible? Is it safe? Does anyone have a resource that would get me started in learning about how to code this scenario.
Thanks in advance,
Kyle.
Easy as pie - you use PubNub for exactly that.
demo similar to your problem:
https://www.pubnub.com/developers/demos/codoodler/
(That demo is in-browser, but it's equally easy to do inside an app - assuming you're an experienced app developer of course!)
more demos:
https://www.pubnub.com/developers/demos/
I can tell you're new at mobile development. Do understand that:
A) In general programming is extremely difficult. Programming mobiles in particular has a lot of fussy knowledge needed as well as broad general engineering skills.
B) We really live in the "age of BAAS" - "platforms" such as PubNub, FireBase, Parse, Realm, Couchbase and so on. (These days you can't really be an "app programmer" .... you can't get a job "programming an iPhone". You get a job doing Firebase development, happening to be on iPhone - you know?)
I believe Apple has documentation on this very topic:
https://developer.apple.com/reference/multipeerconnectivity
The trickier part will be how do you send back and forth data that allows the host to "control" the views of the other devices. If by "control" you want to let the host control things that are outside of your app (like a screen share) I don't believe that will be possible.
I have read many post indicating that we can't send sms on Missed Call, but i would like to know the reason behind that.
Also there was a app called "Agile reply" for iphone but i cant find that app in the app store actually.it seems that it has been removed from the app store
I would like to develop an app like sending sms on missed call / un answered call.that app needs to be posted on "App store".my app needs to run on iOS 4.0 and 5.0
Please share your view on developing app with this kind of functionality and its possibility
why this kind of app will be rejected.
The Agile Reply app didn't send texts automatically upon a missed or unanswered call -- it just allowed you to quickly compose a message to the last number that called.
If Apple have decided they're unhappy with this sort of app, that's the end of the story. They have their reason(s), and whatever you think of those reasons, they're the gatekeeper of the app store; their say is final. Of course it might be possible to develop something like this for jailbroken devices, but that's a different story.
As for the reason that Apple didn't like the Agile Reply app: the following two reasons seem plausible to me (but are also just educated guesses on my behalf):
1) The app accessed private APIs
2) Apple thought that the app didn't offer anything new or worthy: they might have reasoned that it is easy enough to go into the built-in phone app, select the last (missed) call, and compose a message to that number, without the need for a custom app
I have a question for the iPhone Development community. I am currently building my first app, and on two of my views I have some buttons. Sales and Marketing have requested that these buttons do nothing and have the title of “Feature Available in Pro Version” or have a title of an application but when touched, an UIAlertView is displayed stating “Feature Available in Pro Version”.
First off, I think this is wrong from a user interface and experience. Secondly and more importantly, I think this will cause a denial when I finish the application and send the app in to the App Store for approval. I have look into the iOS Human Interface Guidelines and really can not find whether this will be an issue or not. I would like to tell Sale and Marketing that their request is stupid and will not get the application approved and they need to stick to their jobs and quit trying to play programmer.
Any comments would be greatly appreciate.
Quoting http://developer.apple.com/news/ios/appstoretips/
Only display the UI for what your "Lite" version will do. Grayed out menu commands, "more track/car choices" you can see but not select, etc. makes your "Lite" version feel more like a commercial than a product, and an annoying and ineffective one at that.
...
It's important to follow these simple rules not only to create a better user experience, but also because your app will be returned to you by the App Review Team for modification if it is found to have time limits, incomplete functionality, or disabled functionality.
Come up with some better options for your clients. They are not trying to "play programmer", they are trying to market their product. Also, try to mitigate the risk of the app being rejected by getting it in a submittable state as soon as possible, or at least make sure that you have a plan B for the things that you suspect might fail to get approved.
It sounds like you're just looking for a stick to beat your sales and marketing team with - there are quite a few apps out there in the wild that exhibit precisely this behaviour, painful though this might be to you. (The buttons do something after all - they show a dialog.)
That said, it's hard to recommend a more pleasant alternative without knowing more about your app. (Does it have the concept of "levels" for example? If so, you could replace the buttons with a nicer "purchase the full app to unlock additional levels" style message.)
I am pretty sure this never used to be allowed. If you show user interface elements they have to be fully functional. I don't know in which document or agreement this is stated, though.
It also may not cause your app to be rejected, at least not initially. The app may be removed from the store at a later date, though.
Apple has been known to quickly reject apps for non-functional or grayed-out buttons, especially if these non-functional UI elements are just to advertise Full or Pro versions in Lite apps.
Apple has also been known to approve apps with a non-functional button or two (happened to one of my apps, got a bug report several weeks after the app had become available in the App store), but this is probably due to oversight, and not a policy that anyone should count on.
If you want an advertisement for your Pro version, make it look and act like a standard in-app advertisement, and not a misleading UI element. Serving house ads, or mostly (99%) house ads is a widely done practice.
knowing that the review process for apps seems to be rather rigid to some extend I would like to ask if there are any special requrements for an app that is targeted to work with certain Midi interfaces only. The particular reason I ask is that this app can not really be tested when not connected to such an interface. Thanks
There is no specific rule regarding this.
App Store Review Guidelines
To be on the safe side, describe this when submitting the app, there is a text field to add a message to the reviewers.
In the meanwhile I submitted my app and it got rejected in the first phase because I did not include a demo video. So after I created one and put it on YouTube, provided Apple with the link, everything went well.
So as a definite advice not to loose time until Apple comes back after a week or two to just tell you to provide a video - include it right from the beginning....
I'm new to mac/iOS development. I'm thinking of to develop a UI less application by using existing Apps/Libraries.
I want to know whether following things will be possible to make or not, it will be great if someone provides me some insight.
Here are my questions:
Is it possible to show/hook additional buttons on existing contacts
-> contacts view (some additional buttons under FaceTime button)?
Is it possible to route some messages to SMS inbox? where the user
feels like he received/sent the real SMS?
In short: no.
In somewhat longer: iOS applications run in a sandbox that rather severely limits their ability to interact with the outside world. This is for the purpose of protecting the user's security and experience using the device. It MIGHT be possible to accomplish both of those things if you were running on a jailbroken device and using non-public APIS (though frankly I doubt you'd be able to add buttons to the existing contacts list by any means at all). But such an app couldn't be sold in Apple's app store.