I'd like to ask something. I'm going to upload my app to google play. But I would like it to be free in few countries and paid in other countries. My question is - is it possible to do that within ONE UPLOAD (and possibly choose those options separately for each country), without uploading app twice (once paid, once free)? Thanks for answer
As far I know this is not possible. You can set different prices for different countries but the price will be at least around 0.50$. Just published two editions, that is not hard with Android Studio. (you need to use two different package names of cause)
Another way would be freemium so let the app for free in that counties you like and make it to shareware on the other countries. But you need to find out yourself the user's location.
Related
Its my first experience to upload my app to google play store and I personally developed so I dont think so that I used any illegal thing it it but Its in review for last 2 days.
The process can take even more than that, what you can do is make sure that:
-you ask the proper permissions, more permissions you need, more time for the store to give you an answer. If you ask for dangerous permissions, you must explain clearly why you want them, else your app will be rejected.
you describe your app well and detailed. This will improve your chances for fast approval
have all the fields filled in properly, like agreement, pictures and videos of different sizes
don't forget about category and ads. If you have ads and chose that the app is available to kids, you can expect a much more detailed check of your app, which takes longer
check all the warning messages you have on the dashboard. Most of them are very useful info.
My advice is to take time to sort all these as best as you can and later you will enjoy fast approvals and easy updating.
My company needs to upload an app to the store , that will only be available to 80 people over the world that will get the permission to test it.
The ad-hoc method requires their iphones id's to be register with the app, and obviously we dont have it.
Whats the best way, to upload the app to the store ,to let this people to get it ?
(NO, without just go to the review process of apple)
thanks.
Besides the enterprise developer program, Ad-Hoc distribution is the only way to limit your audience.
If you try to game the app store with an unreasonable high price and promo codes (limit of 50 codes per app version) Apple will kick you out of the review process in no time.
Use testflight to get device IDs easier and deploy you app to the testers.
There is no way to do that, for the Adhoc, you must register their UDID devices.
You can upload the app in the AppStore, put it's price high, and give the prople that you want to test the app a redeem code that will download the app free, but i think the number of redeem code you have is 25. If you find anyway to do that, share it with us please.
If the 80 people that will be testing/using the app are employees of the company, you should look into the Enterprise Developer Program. Enterprise development lets you deploy an internal app to employees of your organization that is not released to the App Store. It essentially lets you build an Ad Hoc like version of your app that can then be installed on devices without the need to get UDIDs.
The cost is $299 instead of the normal $99 and there are a few caveats on whether or not your organization qualifies. But if you do qualify, it vastly simplifies deploying an internal app and it gives you specifically what you were asking for - no review and no need to ask for UDIDs. You can put the signed bundle up on a website and simply give people the URL to it for OTA installation, so you don't even need iTunes.
Alternatively, if the end users are not a part of your organization, you can also look into developing Custom B2B Apps. This one comes with a few more hoops to jump through and it also requires an Apple review, but it allows your app to be sold only to specific customers and doesn't put it in the App Store. If you're already a developer with Apple, there's even a WWDC video on it.
Hello I don't understand the ads system of wp 7
Do I need to code something or dropping the component on the botton of my screen is enough
I can't find how much can I get from this... Does the user have to click the add so that I'll get paid.
Thanks
Asaf
With Microsoft ads, through PubCenter, (pubcenter.microsoft.com) your pay is based on impressions, while nearly all others are based on clicks.
To use the PubCenter ads, the ad SDK is part of the Windows Phone tools install. You can find information on using this at advertising.microsoft.com/mobile-apps and at create.msdn.com.
As far as how much you will make, it depends on your app, how popular it is, how well targeted your ads are, and more. eCPM is the rate you're paid, and it is on a bid process, and varies from minute to minute, depending on what ads are available within your targeted categories.
For instance, I have one app that typically makes close to 1000 impressions per day, and brings in about $1.00 to $1.50 per day, depending on impressions and eCPM, of course. I have another app that brings in nearly the same number of impressions, sometimes more, and yet, it only makes me about 20% of the first one. I'm still working on tweaking the ad categories to increase my eCPM so that it will make as much as the first one, but I'm thinking it is part art, and part luck.
Maybe you can find the answer for your questions here: Microsoft Advertising
Is it possible to somehow submit windows phone 7 applications to MS App Hub from Croatia?
In legal way, through some company who will do it for percentage?
Thanks
The supported countries are covered here. This list is being expanded and I understand a lot of work is involved getting everything in place country by country.
App Hub - faq: answers at a glance
Until Croatia is on the list I don't believe there is an option at the moment unfortunately. Perhaps you could try and find out from local Microsoft reps how the process is going and express your interest.
Companies may be willing to submit on your behalf for a fee, but I can't tell you what the legal ramifications of this would be. I haven't seen any companies promoting such a service at this stage.
There is not official standard dealing with the layout of about boxes, which display the credits of a computer software and other information.
What should a good about box contain? And... is it okay to put an easter egg in?
(source: seasip.info)
I generally prefer to make tabbed "About" boxes. The first tab usually displays information about the application (name, version, copyright, etc.). The other tab is usually a log of changes with the most recent changes at the top.
Legal will want their copyright and stuff, marketing will want their branding (even though the user has already bought the product), the dev team will want their names up there in liquid crystal, but what do users need?
App name and version number. Users may need this to troubleshoot problems, perhaps while in contact with tech support or when using a knowledge base. Use a version number system such that this is all the user needs to specify their build. Version number is also needed for the users to know if they can upgrade.
A brief statement of what the app does (e.g., “Photograph and picture organizer.”). Users often end up with software for which they can’t guess the purpose. “About” is a logical place to tell the user what the app is about.
Put the above in conspicuous text at the top of About. Have a single OK button. Everything else that may be required by others in your company really isn’t of any interest to the user and can all be in “fine print.”
You could also include the web site or email for tech support if you can rely on that being stable for years, but usually users have this before going to the About box.
Easter eggs are fine if you think it’s appropriate to have a little fun in your app and your users lean towards the geeky side of things. Just make sure it isn’t something that will alarm a low-end user (or a future high-end developer; see: http://blogs.msdn.com/jensenh/archive/2005/10/20/483041.aspx).
Looking at a few examples of About boxes:
Name of the software
Name of the publisher/author
Copyright and licensing information
Version information
A nice logo
These days, it probably wouldn't hurt to have a way to directly go to the website for the software in the About box itself.
Microsoft's Windows Vista User Experience Guidelines tend to have useful information on designing good user interfaces. I wasn't able to find information specific to About boxes, but the section for Dialog Boxes may be somewhat relevant.
A team in my workplace actually has made the coolest About box ever:
Every time you open it, it displays a different simple game, with pictures of the dev. team (memory games, tic-tac-toe, sudoku, etc)
As for the About page content, that is the best place to have the version / release information so you can offer easy support.
I am using mine as the abstract description and a link to the legal pages and a credits page. If you have a website, its URL should be there as well -- might as well make that click-able into your own web-view browser to your big "Company About" page on your web server (don't launch a real browser, or the user just left your application).
Make it enjoyable to read but be concise. Avoid any scrolling or paging -- except to a completely different set of informational screens.
Also, let it be obvious and easy to dismiss.
By-the-way, if you add an easter egg to an app that is submitted to Apple Store, you have to disclose the sequence for Apple to 'test'; they promise to keep the sequence confidential. If they discover it later, which will make it back to them through forums, etc., then they will automatically pull it from the store.
I tend to add program name, version, company copyright, contact information, license information. I also add various variables for problem resolving. Winows version, servicepack, dll version if i use critical dll's etc. A large application icon. Sometimes I add an easter egg or some keycombo that launch parts of the program meant for debug and support purposes.