Currently designing an iOS app that has functionality including the transfer of in-game currency to real-world currency. ( within Xcode using swift, it’s a mobile game )
Since this app includes the prospect of real money, I couldn’t help but feel that people would tamper with the game mechanics and take advantage of it.
My current idea of keeping the app tamper proof is to have the user fill in form, where not only would the user input all their relevant information, but in the background include users app data showing all their moves and game history ( there is no break of privacy as the app is only a basic game, they don’t input any private information apart from payment info at the end ).
Is there any MUST HAVES I should include in the code to make sure that the game is tamper-proof, or at least a way in which I can spot tampering? ( I assume there is already threads out there, let me know of them that would be great ).
Thanks
Related
I am developing a game with Unity.
Say a player can buy 5x arrows for 0.99$. Do I have to provide the user the ability to restore the unused arrows in order to not be rejected by the AppStore?
I know they say that, if I want to provide the restoration functionality, I have to use my own servers... is there a way to store the amount of arrows a player have without the need of using my own server?
sorry for the offtopic, I really don't have anywhere else to ask :(
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I have done a lot of researches regarding accessing device SIM card data such as SIM serial number and user phone number, and below are my findings :
By using private API for iOS SDK we can extract the needed information from SIM card (If already stored on the SIM card).
The issue related to the rules and regulation for submission apps. On Apple store, since Apple rejects any application accessing SIM card because hey supposed that such behaviors break the user privacy and security.
This functionality used for application not attended for APPStore submission.
References :
How could I read information from SIM card in iPhone?
Programatically get own Phone Number in iPhone OS 4.0
How can I get the phone number of my iPhone device?
Read/write certificates on a SIM card - iOS
all the posts and tutorials that i found said that i can't extract data from the device SIM card without facing apple rejection !!!
My question is ,, is there any way to access SIM card information and publish my application successfully on the Appstore ? and i appreciated any reference to the part in apple submission rules and regulations document that says "NO SIM CARD DATA ACCESS" !!
My question is ,, is there any way to access SIM card information and publish my application successfully on the Appstore ? - No there's no way. There's no direct reference of "No Sim Card Data" in documentation.
As you have already read SIM card data access is not possible using the Apple SDK. Following is the part of Apple Developer Document :
The following guidelines can help you ask for user data in ways that
help people feel comfortable.
Make sure users understand why they’re being asked to share their
personal data. It’s natural for people to be suspicious of a request
for their personal information if they don’t see an obvious need for
it. To avoid making users uncomfortable, make sure the alert appears
only when they attempt to use a feature that clearly needs to know
their information. For example, people can use Maps when Location
Services is off, but they see an alert when they access the feature
that finds and tracks their current location.
Describe why your app needs the information, if it’s not obvious. You
can provide text that appears in the alert, below a system-provided
title such as ““App Name” Would Like to Access Your Contacts”. You
want this text to be specific and polite so that people understand why
you’re asking for access to their information and don’t feel
pressured. Your reason text should:
Not include your app name. The system-provided alert title already
includes your app name. Clearly describe why your app needs the data.
If appropriate, you might also explain ways in which your app will not
use the data. Use user-centric terminology and be localizable. Be as
short as possible, while still being easy to understand. As much as
possible, avoid supplying more than one sentence. Use sentence-style
capitalization. (Sentence-style capitalization means that the first
word is capitalized, and the rest of the words are lowercase unless
they are proper nouns or proper adjectives.) Ask permission at app
startup only if your app can’t perform its primary function without
the user’s data. People will not be bothered by this if it’s obvious
that the main function of your app depends on knowing their personal
information.
Avoid making programmatic calls that trigger the alert before the user
actually selects the feature that needs the data. This way, you avoid
causing people to wonder why your app wants their personal information
when they’re doing something that doesn’t appear to need it. (Note
that getting the user’s Location Services preference does not trigger
the alert.)
For location data, check the Location Services preference to avoid
triggering the alert unnecessarily. You can use Core Location
programming interfaces to get this setting (to learn how to do this,
see Core Location Framework Reference). With this knowledge, you can
trigger the alert as closely as possible to the feature that requires
location information, or perhaps avoid an alert altogether.
You can refer this
I understand that I have to use the UIAccelerometer to detect which angles that will exist in a regular golf swing.
The best equivalent that came to my mind is that I want to use the iPhone just like the Nintento Wii control.
Is it possible to swing the iPhone like a golf club and be able to decide:
Wheather it's a roughly accurate swing (if it's more like a tennis swing = throw error)
Perhaps store the angles the iphone registers on the "back swing". If I store five values each x second on the "back swing" and then check if these values are roughly equal to the "front swing".
I also need to decide how hard the swing is, perhaps if I can check this a moment before the iphone reaches the default position (start position before starting the swing movement). I know that I can't calculate the speed between two positions with UIAccelerometer, but maybe I can solve this in some other way?
Answer from Apple Review Team on this question
Thank you for contacting the App
Review team. Apple is not able to
provide pre-approval to developers for
proposed application submissions or to
review and comment on application
concepts, including business models.
That said, the concept does not
violate the guidelines; however, the
app will need to be evaluated to
ensure the implementation is in
compliance.
Personally I think an app like this would be approved, but an app where you is supposed to throw you device as near as possible to a location should be disapproved. This is how I interpret this.
Anyway, I've learned that my question, which was if the swing was possible, is absolutely doable with the usage of the Accelerometer with a High pass fitler and a Low pass filter.
Have in consideration: If you are about to develop an app with the same concept, don't get angry if it gets rejected.
There's a reasonable chance that Apple won't let an app like this into the app store. Read the human interface guidlines: they say to not encourage the user to do anything which might cause them to damage their device. And with doing a golf swing, I can imagine somebody somewhere letting go of their iPhone and then kablooie...
http://developer.apple.com/iphone/news/archives/2010/february/#corelocation
Can anyone tell me what is the exact description of an ad and just a hint for a user?
We are developing a library that shows small banners depending on user's location. E.g. we are passing a cafe - we have a banner about this cafe, we are passing a church - we have a banner about this church. The library is to be re-used in other apps.
So from one point of view we are advertising a cafe, but from another point of view we are giving the user an advice about places to eat around him. So what is the border between an ad and advice to a user?
I think the problem is that such an app tracks the location of the user and location specific ads will constantly remind the user that their physical location is being tracked.
This is an obvious privacy and security issue but I also think Apple wants to prevent users from experiencing that creepy feeling that comes from knowing somebody is tracking you against your will.
In order to feed the iPhone location based adds, you have to upload the location of the iPhone to a server, process the appropriate adds for the location and push them back. That means that an external 3rd party, that neither Apple nor the user can control, is constantly tracking the location of the phone while the app is active. Since an app can capture info identifying individual phones, that turns the app into spy program.
Even if you actually did all the processing inside the app on a single phone e.g. looking up an internal local database, the user would still most likely assume they were being tracked remotely.
There is no way Apple will risk the damage to the iPhone's brand that would come from news stories screaming, "iPhone App Secretly Tracks User's Locations Anywhere in the World!"
The library you have in mind is clearly verboten. You could might get way with it if had a mechanism for constantly asking the user if they wanted to load location specific ads.
(BEGIN RANT: As an aside, I would say this sounds like something the explicative-deleteds in marketing came up with. They think "Hey, we can push location targeted ads at users and force them see those ads when they use any of the apps with the library! Think how great that will be for advertisers!"
Marketing driven design is almost always a disaster. If they started the design with the idea, "Hey, I think I as a user would like to have the option of seeing ads relevant to my location with a mechanism I control and which protects my privacy and security," then they would come up with a much better library.
In the long run, you make money by giving end users more power and control over their work and lives. You don't make it by strapping them down and force feeding them what you want.
If you personally wouldn't want the functionality and no users have asked you for the functionality, then its probably a bad idea. END RANT)
Edit01:
Let me address this:
So from one point of view we are
advertising a cafe, but from another
point of view we are giving the user
an advice about places to eat around
him. So what is the border between an
ad and advice to a user?
I used to work at Apple in several capacities so I understand a bit how they think.
An ad is something pushed onto the user with any prior action of the user's part. The user doesn't request the ads, doesn't select the ads may not even want the ad but they just appear anyway.
Advice is something the user ask for explicitly. An app with a button that says "Show adds for businesses in your immediate vicinity" would fall under the heading of advice. Even an app whose stated function was to show adds for businesses in the vicinity would be fine. In both cases, the user request specific information. It is not pushed onto them. More importantly, the user can control if they send their location or not.
I got caught in the nutcracker back when Apple thought it was a good idea to have dialogs popping up telling people how to upgrade to Quicktime pro. It caused no ends of problems for end users especially those in institutions because it took control out of the hands of end users and administrators. I got to stand between irate customers and the genius that thought of the idea, which turned out to the actual genius Steve Jobs. Eventually, he saw the light and the desktop ad experiment was terminated.
Jobs and Apple learned their lesson. Don't force ads on end users. Especially don't tie ads to the functioning of the software (in this case, the location manager.)
The big thing in Apple's announcement is the part that says: "If your app uses location-based information primarily to enable mobile advertisers to deliver targeted ads based on a user's location, your app will be returned to you by the App Store Review Team for modification before it can be posted to the App Store."
Is the major function of your app to advertise to users -- regardless of the fact that they may ask for the ads or not? If the major function is to advertise to users based on their location or the greater portion of Location Services usage is for the purpose of advertising to the user then Apple will reject the app. Period.
I finished building an app that allows beaming of photos, contacts and text clips over Wi-Fi
IPhone to IPhone and IPhone to desktop.
I want to decide on the feature set of the lite version of my IPhone app. I also want to come up with a pricing model. So the question is, which of these components should be free, and for which I should be charging for ?
For example, the lite version could have all features except the ability to interact with the desktop version - that is, it would work IPhone to IPhone, but not IPhone to desktop. The paid version would be able to beam to the desktop. In addition, the desktop version would be free, so you could share it with family and friends.
Alternatively, there would be a single free IPhone version and I would charge for the desktop app. The only thing here is that I would have to setup server side code for managing registration codes.
One reason to make your desktop app free and the iPhone app a paid product would be to take advantage of Apple's app store and their payment processing, hosting, etc. While I know 30% seems steep for what Apple provides, it is nice to have that part of the business be handled by someone else. For example, you will never have to deal with credit card processing or have to issue refunds - Apple does all that for you.
I like the mechanism that is more suited to viral distribution and giving people a good taste of all the features, before they are sort of convinced to go for the paid version. The marketing value of an app that can be freely tried out once one user recommends it to another, is invaluable. If someone recommends a product to me and I have to pay for it, then I probably would put off trying it till alter when I have learned more about it. However, if it is free, I can download and try it without feeling like I need to do more research prior. Once I like, and am hooked on it, then I will want locked functionality that I would have to pay to unlock.
I'd stay away from selling, payment processing, and reg code management, if your expertise is in coding - you'd make yourself more money writing more code than writing reg code management utilities...
Good luck.
I'm not sure charging for either is the best idea. If you keep both tools free, you get people trying (and liking) both apps. Viral distribution will ensure a decent user base. Once people use both tools, they're more likely to pay for the next part, which is the connector software.
I like your idea of three parts: a free iPhone app (Let people share photos on their iPhone), free PC app (There are hundreds of photo viewing apps, free... Don't try to charge for them, that way lies pain) and paid connection between 'em.
That way:
You get people using your iPhone app virally (To share with each other's phones & try out the application)
You get people using your PC app virally (Because the cost to try is nearly null)
The connection can be sold through Apple's iStore, so you don't need to do the money handling side
You could even make the connection component a subscription, but as an end user I hate that idea unless I get some additional functionality from it being a subscription (Like free hosting).