I tried publish my app: http://pomidoro.codeplex.com/ on Windows Store and certification failed because:
'Your app doesn't meet requirement 1.1.
Comment from tester: This app didn't appear to provide value or didn't seem useful to the reviewer.'
Is that means that I do not have any chances to publish it anymore?
No, you can make some tweaks and publish again. Here are some thoughts:
It may be an issue of marketing, and modifying the description that you submit with your application will fix the issue. Your description at http://pomidoro.codeplex.com is pretty good, but maybe you could add some data around how it helps you work more efficiently in case the reviewers aren't familiar with Pomodoro. There are tips on writing a good description/app listing here.
Otherwise, you could add some extra features to the app so it's more than just a timer. Can the user record their whole To Do list in the app, and then choose what to focus on during the pomodoro from that? Or, allow them to rank each pomodoro as effective/not effective after the timer goes off and keep historical data so they can see what times of day they are most effective? And so on...
Here is the first post in a blog post series on common certification failures for the Windows Store and how to fix them which might also be useful.
Good luck!
Related
I am having problem loading metaplex store. I did a direct fork from the main metaplex-foundation github master and deployed it on Vercel via their instructions here: https://github.com/metaplex-foundation/metaplex/blob/master/docs/deploy.md
It builds without errors, but when I load the site, it just keeps loading forever and wallet cannot be accessed or connected nor the site be accessible.
I followed all instructions from their link above and ensured I have the address in the.env.
I even added a URL in a new CNAME file I added in packages/web folder, from previous experience.
How can I resolve this?
For starters, metaplex acknowledges that the current storefront (v1) has quite a few issues that are impacting users. No further fixes will be forthcoming given that the storefront has been officially deprecated as of May 2022. With that out of the way, a high level overview of the issue you are describing is as follows:
when you start a storefront (SF) that has no auctions, it needs to scan quite a bit of data to figure out what it needs to display. This scan includes a few chunky calls to the RPC that may or may not work depending on the state of the network. This step is also a bit buggy and can end up in an infinite loading loop.
when you fire up the first auction, SF creates a storeindexer object on the chain. This object is used to index the first auction and all the subsequent auctions.
if SF finds a storeindexer object on startup, it bypasses all the madness in step (1) and instead uses the storeindexer to figure out what data is needed. That doesn’t require any gPA (getProgramAccount) calls either which is nice.
it’s a bit of a catch-22 because in order to start the first auction you need the storefront, but you also need an auction to avoid the loading problem in step (1).
After the first auction is up you should be able to resume using your SF as normal.
You may try this version of the storefront to get around the infinite loading problem. It's quite barebones in terms of functionality and there is an issue with SPL tokens that have decimals other than 9. However it does get around the infinite loading problem and you should be able to list your first auction with it.
https://github.com/neftworld/metaplex-storefront-v1
However, STOREFRONT IS DEPRECATED SO CAVEAT EMPTOR
I'm using James Montemagno's Plugin.InAppBilling library for Xamarin to do iOS and Android in-app subscriptions. It has worked mostly correctly so far, except that once in a while, on iOS only, InAppBillingPurchase.PurchaseToken comes back null from calls to PurchaseAsync and GetPurchasesAsync.
For example, in my Restore Purchases logic, I have code similar to this:
var purchases = await CrossInAppBilling.Current.GetPurchasesAsync(ItemType.Subscription);
// Sometimes we receive purchases with no PurchaseToken.
// Can't verify the purchase without a token.
var verifiable = purchases.Where(p => !string.IsNullOrWhiteSpace(p.PurchaseToken));
At this point, verifiable sometimes has a different count (0) than purchases (1).
So far, this has seemed to happen when the user purchased using either store credit or a gift card, and only on iOS.
Also, I'm not sure if this bears on the problem, but I am not using the overloads of PurchaseAsync and GetPurchasesAsync which take IInAppBillingVerifyPurchase, because I use server-side verification exclusively (no client-side verification). My workflow is to make the purchase, add the resulting InAppPurchase object to a queue for processing, and then send it to our server as a separate step, for validation and association with the user's account. However, if this is not a valid workflow or if it is known that sometimes PurchaseToken data will be available via IInAppBillingVerifyPurchase.VerifyPurchase but not attached to the InAppBillingPurchase objects returned from the methods above, I would certainly like to know about that. (For what it's worth, I've read the documentation and don't see anything that suggests this.)
Thanks in advance for any help.
Okay, I think I've learned enough to provide useful information for anyone else dealing with this issue.
First, I've figured out what Apple means by "iOS 6 style" and "iOS 7 style" receipts. These do not refer to the version of iOS that creates the receipts. (My up-to-date iOS 12 device still can and does generate "iOS 6 style" receipts.) Instead, these refer to two different receipt formats that were introduced in the respective iOS versions.
iOS 6 style receipts come from SKPaymentTransaction.transactionReceipt and contain information about one specific transaction. This field is now deprecated by Apple.
iOS 7 style receipts come from the app bundle, via the location named in NSBundle.mainBundle.appStoreReceiptUrl. These receipts contain a full manifest of all purchases ever made by the user. The receipts don't expire either -- you can always send them to Apple for validation (though, obviously, individual transactions contained within might show as expired in the response). These are the receipts you should prefer.
The reason this is important is that if you're using the Plugin.InAppBilling library, the InAppBillingPurchase object you get from calling something like PurchaseAsync contains the deprecated iOS 6 style receipt in its PurchaseToken field.
I'm still not sure why it is sometimes present and sometimes null, but seeing as the underlying source of the data is deprecated, it's probably safe to assume that this can and will happen. Therefore, it probably makes sense to cut over to the iOS 7 style receipts as soon as possible.
Note that when you call PurchaseAsync, if you specify an implementation of IInAppBillingVerifyPurchase, your IInAppBillingVerifyPurchase.VerifyPurchase method will receive the newer iOS7 receipt instead. However, the InAppBillingPurchase object returned by PurchaseAsync still gets an iOS 6 style receipt (if it gets anything at all).
Personally, I like the InAppBillingPurchase object itself. It has useful information packed into a convenient package. Since I want to keep the serialized InAppBillingPurchase objects in a queue so that I can retry validation if there are problems with our servers, connectivity, etc, what I'm doing is immediately replacing the PurchaseToken property with the iOS 7 style receipt that I manually retrieve from the bundle.
If you do this, be sure that your code handles the slightly different formats of the iOS 6 and iOS 7 receipts properly. (Our earlier attempts had some errors stemming from not properly understanding what these terms meant.)
I hope this is useful to someone out there. Good luck!
I am building an application that simulates user input (command+c and command+v). Before sandboxing it, everything worked fine, but now I am getting these errors from the console:
Firstly, when I fire it up:
5/27/13 1:35:11.980 AM appleeventsd[54]: A sandboxed application with pid 5343, "CopyBoard" checked in with appleeventsd, but its code signature could not be validated ( either because it was corrupt, or could not be read by appleeventsd ) and so it cannot receive AppleEvents targeted by name, bundle id, or signature. Error=ERROR: #100013 { "NSDescription"="SecCodeCopyGuestWithAttributes() returned 100013, -." } (handleMessage()/appleEventsD.cp #1755) com.apple.coreservices.appleevents.peer.0x7fa9b0411260.xpcq
Then, when I try to simulate command+c, I get:
5/27/13 1:52:22.980 AM WindowServer[85]: post_filtered_event_tap_data: Sender is prohibited from synthesizing events
5/27/13 1:52:23.000 AM kernel[0]: Sandbox: sandboxd(6515) deny mach-lookup com.apple.coresymbolicationd
5/27/13 1:52:24.252 AM sandboxd[6515]: ([5343]) CopyBoard(5343) deny hid-control
I'm looking for a solution that would allow me to copy and paste globally in a sandboxed environment. Is it possible that the Accessibility API is a good answer? Has my problem got anything to do with how I'm simulating user input? I'm very confused, thank you very much for helping.
The sandbox is designed to prevent exactly what you seem to be trying - allowing an application to simulate a user is defined as a security issue. If you have a narrow requirement which can be done safely you can submit it to Apple thorough bug reporter as an needed improvement to the sandbox.
The Accessibility API is not supported in general for this reason - no playing with other apps! This did not go down so well with all the developers which used it...
You can use AppleEvents in limited constrained circumstances and with the appropriate entitlements.
You'll probably need to go to developer.apple.com and read all the documents/view videos/etc you can find to see if what you wish is going to be possible.
The only point of hope I can offer you is that the sandbox is a moving target, so you may find you can do more than the above suggests. Go read. Good luck.
I kick off 5 uploads (of varying size) via the BackgroundTransferService. I have the following questions about the way it works:
It seems that on the emulator it does 2 uploads at a time. Is this how it works on the actual device? Can I programmatically change this behavior?
Can I count on the uploads going out in the order that I submitted them? I seem to be getting conflicting results in my testing.
When I inspect the BackgroundTransferService in my application, does it contain requests from other apps as well or just mine?
Do I need to reconnect events for all the BackgroundTransferRequest objects when coming back from being tombstoned? What about coming back from being reactivated?
Do I need to disconnect events from the BackgroundTransferRequest when I remove it from the BackgroundTransferService.Requests collection?
When I try to upload a non-existing URL:Port (on the localhost), the TransferStatus is reported as WaitingForNonVoiceBlockingNetwork. The upload never actually completes/fails. Is this how it is on the device? Should I remove the request when it encounters this TransferStatus?
You cannot influence the behaviour of the BTS. If you don't like the way it works you can write the transfer functionality as part of your own application but then you have to handle running in the background yourself.
There is no guarantee on sequence.
The BTS may be handling requests from other apps but you won't be able to see the details. Requests() will only return details for your app.
Surely a quick test will tell you this.
It's good practice to.
Have you checked the TransferError property whe you reach this situation? This is a perfectly valild status in other situations and so you shouldn't treat this as a automatic fail.
Is anyone now online able to perform receipt validation in a Mac application?
Have you used the ASN generated files in the application?
Are you able to produce a sample receipt by automatic popup of the iTunes authentication?
The best way I know to check receipts is by letting Receigen generate the code - different for each new version. It's probably more secure than what you can develop in a reasonable time.
I have it working, but i am using open source code to do it.
Using this code in your main , and changing your app bundleID/version, it validates the receipt.
In this question you can see the code i used.
Mac App Store Receipt Validation Code?
I've got an example receipt at my question here (Can Purely On-Device In-App Purchase Receipt Validation Be Done With iOS6?). I've generated the ASN files and am trying to use them now. I used the compiler here. I'm not sure if it all works though, just starting testing in earnest now.
Chris.