BREW TBT Process? - brew-framework

I am new To TBT Process. If i want to test my build in TBT for a particular device, I have to pay, OK... but If want to test for another device model, do I have to pay again? After passing TBT process, how can I sell that build, will they provide single file or MOD with MIF, like that? What I have to go through result build? Any help please?

With TBT, you pay each time you submit a build. You pay less if you are adding a device to your existing application submission.
Once the app passes, it is listed in your Qualcomm extranet site. No, you do not get a build. Qualcommm holds the certified build with them and then you contact the operator willing to have your application listed with the content id.
Its a completely locked down system so my advice is not to get into the platform unless you have a operator willing to take on your application.

Related

XCode test Distribution ipa in device

I have a little problem and I am wondering if this is possible. I have just finished updating an app with push notification for a client. I don't have a hold of the server side so I tested the push by modifying the app id and just make it as my own temporarily, created the necessary certificates and provisioning profiles and then tested it using PushMeBaby app. All works fine without problems.
And now, the client wants to publish it and he gave me the distribution certificate and provisioning profile for distribution. I am not a member of his team but I somehow find a way to build it using the command line.
Now comes my problem, I wanted to test it first on my device to check if the push notification works. The server is already setup since it is already existing in the store. I know for sure that the push will work, but somehow I really feel the need to test it first on my device. I tried to request him to use testflight for testing but he said he doesn't know how to do it. I tried to present myself to do it but he doesn't allow it because the original developer made some anomalies with his account, so as much as possible, he won't give it to me saying there must be other way to test it myself.
And so I asked, is there any way to test it with just the distribution certificate and provisioning profile provided? If not, what would be the best alternative to do it, considering having the client do a very minimal and easy stuff on his side, if any.
Hoping for someone to actually give a hand or a hint.
Thanks in advance.

The new Test Flight is worthless for adhoc distribution. Any work arounds?

I finally got an invite to an internal tester to work using iTunesConnect and the Test Flight app. I find that for adhoc distribution this is simply not going to work...
30 day expiration is way too short.
In the old Test Flight, a tester had multiple devices. With the new test flight each invitation is good for only one device. If you try to use the invite on a different device it says it is already in use.
I don't see any work around for the expiration period, any ideas on a workaround for the second issue, or am I doing something wrong? Is there a way to add devices to the the user account.
Perhaps, this is not the vehicle I should use for my adhoc distributions? Other suggestions are welcomed.
The new TestFlight works better than the old one for multiple devices. The invite only works once, but it's tied to the Apple ID you use it with, log into the TestFlight app with that same Apple ID on another device and you can just install the app. Don't try to reuse the invite.
I personally find the Internal testers useless though, since you have to grant those users access to your iTunes Connect account. There's a work around where you can use your own email, something like "me+user1#whatever.com" and have the invite come to you, then you just forward the invite link to the user you want to use the build and not have access to iTC, but that's a pain.
The best plan is, send the app for TestFlight review, get it approved, then add all of your testers as External testers. You can submit new builds without going through review each time by keeping the version number (CFBundleShortVersionString) the same, increment the build number (CFBundleVersion), and checking the option that says "no significant changes for this build".
If you don't need to support iOS 7, the new TestFlight is way better than the old one. With the initial review being the only downside.
Here's a quick guide that explains what you can do with the New TF:
New TestFlight • Quick need-to-know guide
There are two ways I can think of.
Get OS X Server and add the phones individually to your Provisioning profile. You will be limited to 100 phones, but any of those phones can login to the server and download the latest build on to their device.
Get an Enterprise account. You can't release to the App Store with an Enterprise account however.
You can import your devices to testfairy from test flight
https://app.testfairy.com/testers/testflight-export/
This I haven't tried yet.

Do I need to protect my desktop app if distributed over AppStore?

I have made a simple desktop app that I want to sell through the AppStore. Of course I want to be protected against piracy. Does AppStore give any protection? How does that process work?
For instance, what prevents a dishonest person from buying my app and then upload it on a torrent and share it with others. If these other people download my app, will they automatically be asked for their identity check (Apple ID and password), the first time they try to use my app, thus preventing them from using it if they have not bought it legally.
If this identity check does not happen automatically, then do I need to add some code in my app that will ask for the identity check. If so, where can I find info about how to do that?
I'm not entirely sure how this process works. Could somebody shed some light on it?
Mac App Store slips a receipt each time it is downloaded into the bundle. The receipt contains information about the computer used (the so called GUID) and the user logged into the App Store.
See here how you should validate the receipt:
https://developer.apple.com/library/mac/releasenotes/General/ValidateAppStoreReceipt/Introduction.html#//apple_ref/doc/uid/TP40010573
If you implement the GUID validation as described in the document, the app will not run on any other computer.
Also check the signature of your code to make sure it has not been tampered:
Verifying app's signature by code
Your application, when downloaded from the App Store, contains a receipt. The receipt contains proof that it was downloaded onto this computer from the App Store, and the ID of the application. There are instructions somewhere on Apple's website that tell you how to verify the receipt and what to do if the verification fails.
That said, you are much better off concentrating on writing an app that people actually want to buy. People who pirate your app wouldn't hand over money if it couldn't be pirated. They would do without it, pick some free app, or pick a different app that they can pirate.
And I'm quite sure that any copy protection you build into your app yourself will get it rejected from the App Store.
Even though the answers I've got were helpful, they didn't quite provide the answer I needed. Looking around I found a software called Receigen from Laurent Etiemble, and the FAQ on his site (http://receigen.etiemble.com/faq.html) gave many answers for what I was looking for. For instance
What is an App Store receipt validation ? Why is it needed ?
Basically, an App Store receipt is what an application must check to ensure that the copy is genuine and can be run.
What happens if I don't check the App Store receipt ?
Well, anybody with a copy of your application can run it, with or without proper authorization.
Is the code receipt validation easy to write?
No because it requires deep understanding of cryptography and secure coding techniques.
It didn't hurt either that Receigen generated code that freed me from dealing with receipt validation code. Receigen takes care of this part so I can focus on what is really important for me: my application.
Yes, it costs money but personally I am more than glad to pay it, because I find this part of the development tedious, boring and complex.
TPInAppReceipt is a great package for this.
I was able to easily add local receipt validation after trying many others solutions less successfully:
https://github.com/tikhop/TPInAppReceipt

a replacement to ad-hoc on the appstore

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.

Check if Mac App was taken from Mac App Store with Cocoa

I'm trying to give a license to all the users who have bought my app from Mac App Store in order to give them faster updates.
What i was thinking is to do an update for the Mac App Store version of the app that will let user register from within the application itself. But i'm having problems figuring out how to test if the application was really taken from Mac App Store and not from a pirated source.
Is there a way to test if the user bought the app from AppStore. Apple does not release this info - as if it would - i could just test if that user email is in the list of people who downloaded the app from AppStore.
Thank you in advance for the help,
Bogdan Vladu
You could have the MAS version of your application copy the Apple-issued receipt to the Application Support folder.
The independent version could look there for a valid receipt. If there is, it will behave like the fully licensed version. If there is not, it would go to demo mode.
If you're making enough money from this app to pay money for DRM and obsfucation, go for it. It might slow down the pirates enough for it to be a profit for you.
Otherwise, you're pitting your own time and skill against everyone who's interested in pirating your app. It's a losing battle, unless your app is really unpopular, in which case you've lost again.
In short, there's no algorithmic way of making sure. Code obsfucation is the way to go, and hope that the pirates don't find the "check-for-tampering" module.

Resources