I'm trying to figure out if its possible for programmers to build an itunes client app for iphone or android where the user has the option to browse and listen to the song preview, something similar to this page: itunes link maker
I greatly appreciate any pointers or links in this direction
thanks
I would imagine your main problem is going to be legal rather than technical. The Apple Website's terms of use say:
Except as expressly provided in these Terms of Use, no part of the Site and no Content may be copied, reproduced, republished, uploaded, posted, publicly displayed, encoded, translated, transmitted or distributed in any way (including “mirroring”) to any other computer, server, Web site or other medium for publication or distribution or for any commercial enterprise, without Apple’s express prior written consent.
I'd be surprised if an iTunes Store Browser application passed Apple's approval process since the iPhone already has one and it's even more unlikely that Apple would let you use their content for an Android application.
Try this.
You'll notice that there is a field called "previewUrl". This gives the url to direct to for the preview of the song. It's not hard to play around with the link to generate content for whatever you're looking for. Make sure you've got an affiliate license first..... May as well make money out of any purchases.
Related
I've been researching for ages and still cannot find an easy solution that perfectly. So i stopped and figured i was going about this project the wrong way. All i need is an easy solution.
My project requires me to make a website that has forms (fields include images, text, urls, colors). When the user submits this form, somehow (THIS IS THE KEY QUESTION), gets sent to Xcode so that it can be used in and iPhone app.
My questions: What is an easy to use program to make a website that can do what i said? How does my website connect to Xcode (supply it with the data)? Is it possible for my app to check for newly submitted info?
Keep in mind that i don't have much coding knowledge as far as websites and i only a little about making iPhone apps (Yes, i have made some but not as advanced as this)
Thank you in advance!
It sounds like you want to build an IOS app that can retrieve user submitted data from the server.
Your form will have to post the data to the server where it is stored in your database. Images will have to be uploaded to the server as well.
You can then build a server-side api that returns data to the IOS device upon request. You can have your IOS app regularly request data from the server, receive the response and store what you need on the device.
There is a lot more to it of course, but from what I can gather from your post, this is what you're looking to do.
The workflow you describe doesn't make any sense.
It starts out easily enough: you have a website that has a form with a submit button. No problem there. Hitting submit likely does a POST to a server somewhere. Again, no problem.
Then you say the form data has to ultimately end up in Xcode. This is where things are really muddled. Xcode is a programming IDE for Mac OS X. I'm not sure how or what it has to do with handling data from a Web form. The two things are, for all intents and purposes, completely independent technologies.
Please describe in much more detail exactly why you think you need to "send data to Xcode". Otherwise, your question, as written, is unanswerable.
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 am new to iphone stuff. After deploying an application in iTunes is there a way to find out the number of iphone/ipod touch which has installed / uninstalled this application ?
During uninstall the user is asked to rate the application, how to get that information with a developer license credentials ?
Apple tells you the number of sales (and the number of upgrades) in iTunes Connect. What they don't tell you is how many people have uninstalled your application or, more importantly, how many people are still using it n days after installing it.
You may be able to get this information (and more) using one of the third party analytic tools such as Flurry, although Apple has recently started to object to service like them. Another option would be to gather the same kind of information on your own server.
It would be really nice if Apple provided better information but, unfortunately, they don't at the moment.
All this data is provided through Apples iTunes connect site
https://itunesconnect.apple.com
Additionally you could subscribe to one of the support sites like
http://www.appfigures.com
which will give you nice graphs on sales etc
You should also take a look at Flurry Analytic's. Not only will it tell you how many unique devices it has been installed on, but you can add events as well. So lets say your app has a "Featured Listings" area or something like that. Flurry will log how many times people enter into the "Featured" area. It will help track conversion rates...
Also shows you the navigation path the user took. So they click on , "search", then they click on "homes", then they clicked on "featured"... yada yada yada... it provides excellent information.
If your app uses Core Location you can even see a dot on a map as to where the user was when they did all of this.
http://www.flurry.com/
-LT
The information provided by iTunes Connect is the number of downloads of your app. The ratings and reviews are actually not provided via iTunes Connect, but you can find it indirectly on the app store.
There are some services that aggregate all this information for you. A new one is www.appannie.com which shows you both downloads and ratings.
For number of installed Apple just updated https://itunesconnect.apple.com site you can adjust the date range in the middle of screen (using the slider) or by adjusting the dates on top left corner after navigating to sale and trends screen to see how many downloads you have had.
Regarding In App Purchases, I can find a lot of information on all the technicalities of actually making purchases and interacting with the store (how to retrieve product information, verify receipts, etc), but I can't seem to find information on guidelines or special instructions for preparing the actual "apps" or "components," whatever they're to be considered, which will act as the In App Purchases.
For instance, once a component is downloaded into an app, where does it exist in the overall architecture of the app? How do they combine to join forces? How do they know about one another. If I have a game, and using In App Purchases I allow users to both download new levels, but also download new game play modes that can affect any of the built-in or downloaded levels, how do I prepare all of these assets so that they integrate?
I'm not looking for a tutorial, per se, but would love to know if anyone has had experience with In App Purchases or knows of a useful reference besides Apple's In App Purchase programming guide which only speaks to the specifics of making the actual download transaction.
The things you download aren't really "apps", they're just data files like anything else your app can download.
Sometimes, they're not really that, they're just effective "switches", i.e. all of the functionality and data is there in your code already, but it's just protected by a line of code like
if (user has purchased extra levels)
add extra items to menu/list
You aren't allowed to download new executable code; I admit I'm not sure how carefully Apple works to prevent you from downloading scripts that control your program's behavior, since it would be very difficult for them to tell what is intrinsic to your original app or not.
In my own programs, I've put the control logic and tables into the main application, and separated out big resource files into a separate ZIP file. When the user buys the add-on pack, they do download that ZIP file of images which keeps the original application size down, and the program just uses those images out of the documents directory instead of the application bundle like it would if they were built in.
I am using the Urban Airship in-app purchase support, which insulates you from running your own server or learning most details of the StoreKit, at the cost of a slice of your revenue.
You can let the levels be in the app from the beginning and just let them become available when the user pays an in-app level. This is by far the most simple solution.
If you want to have downloadable levels you will need to set up an own server that will deliver and check correct purchase transactions with apples servers. You will also need to create all the download and architecture to load and use these levels into your app.
But, you can have a look here http://urbanairship.com/in-app-purchase/ for help in creating downloadable items.
This code will get you going: works on the simulator too: https://github.com/boxerab/InAppPurchase
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).