I think what your trying to say is that your using TinyPNG to lossy compress your PNG files before importing them to C3. But that it's having no effect on the export size of the project.

This is expected, TinyPNG works by converting the images to 8 bit indexed PNG files ( 256 colours ). However, when C3 exports images it combines them into spritesheets in the standard PNG format ( 32 bit - 4.2 billion colours ).

Choosing the option "re-compress images" in the export should losslessly reduce the size of your images, this is a good starting point. Alternatively you can run TinyPNG on the Spritesheets after export if you want, but given that you will have many images on the same sheet reducing it to 256 colours may cause issues with image quality.

Reducing the physical dimensions of your source images is generally the best approach to reducing memory usage.

If that doesn't work out it would be useful if you could create a bug report for this, it'll make it easier to track down whats going wrong here. https://github.com/Scirra/Construct-3-bugs/issues. Please provide a minimal project, based on your actual purchase flow code and replication steps on how you building your project. I would appreciate it if you gave a detailed but concise report. Trying to debug an in app purchase will take quite a chunk of my time, so I want to make sure I'm doing exactly what your doing. I'll try my hardest to get this sorted out for you. I can appreciate that testing these things can be fairly tedious / frustrating.

If you do figure out what's wrong in the mean time, then also let me know so I can either put a note in the manual or sure up the code in that area.

Okay good to know, this is the test app I use https://www.dropbox.com/s/wy9nfmi1fnk6nlj/Purchase%20Demo.c3p?dl=0. It should work fine on Android and iOS.

The "Purchasing product [...]" log is where the JS code asks the plugin to start the purchase, so it hasn't made it as far as the native code yet.

So you've tested the live application on a physical device with a real user account and the products are still not appearing?

cybertron7 are you using the simulator or a device for testing? Have you signed into the app store with a test user ( you can generate these through iTunes connect ).

Ah just noticed your putting all your products into a single registration call, it only accepts a single product ID at a time.

I wasn't questioning if you had registered your product, just if they were available to purchase. Having the products registered with iTunes connect doesn't necessarily mean that it is available for a user to purchase, so it's always worth checking with the store. You can use https://www.construct.net/gb/make-games/manuals/construct-3/plugin-reference/mobile-iap On Product available and Is Product Available for this.

Android phones use a format called APK for installing applications. They come in 3 flavours normally; debug, unsigned release and release. I recommend you check out the latter part of this tutorial: https://www.construct.net/gb/tutorials/building-android-apps-apks-in-construct-3-19. I'm presuming there is one in your zip file?

I normally install APK's by transferring it via a usb cable into the phones downloads folder, then just opening it on the phone ( will automatically start the installer ). Another good method is by putting it on your google drive, which might be easier if your using a mac ( historically they haven't liked talking to android phones ).

There isn't a default, it will show whatever you selected last in the cloud menu.

How long it takes to load an interstitial is network dependant so it varies I'm afraid. I couldn't find any specific information on how long you can keep an interstitial loaded, but you may find some of this useful (taken from the admob getting started guide):

[quote:thydbwmi]

Consider whether interstitial ads are the right type of ad for your app.

Interstitial ads work best in apps with natural transition points. The conclusion of a task within an app, like sharing an image or completing a game level, creates such a point. Because the user is expecting a break in the action, it's easy to present an interstitial ad without disrupting their experience. Make sure you consider at which points in your app's workflow you'll display interstitial ads and how the user is likely to respond.

Remember to pause the action when displaying an interstitial ad.

There are a number of different types of interstitial ads: text, image, video, and more. It's important to make sure that when your app displays an interstitial ad, it also suspends its use of some resources to allow the ad to take advantage of them. For example, when you make the call to display an interstitial ad, be sure to pause any audio output being produced by your app. You can resume playing sounds in the onAdClosed() event handler, which will be invoked when the user has finished interacting with the ad. In addition, consider temporarily halting any intense computation tasks (such as a game loop) while the ad is being displayed. This will make sure the user doesn't experience slow or unresponsive graphics or stuttered video.

Allow for adequate loading time.

Just as it's important to make sure you display interstitial ads at an appropriate time, it's also important to make sure the user doesn't have to wait for them to load. Loading the ad in advance by calling loadAd() before you intend to call show() can ensure that your app has a fully loaded interstitial ad at the ready when the time comes to display one.

Don't flood the user with ads.

While increasing the frequency of interstitial ads in your app might seem like a great way to increase revenue, it can also degrade the user experience and lower clickthrough rates. Make sure that users aren't so frequently interrupted that they're no longer able to enjoy the use of your app.

Have you tried checking if your products are available to purchase? You should be checking this in your event sheet anyway before displaying the purchase buttons.

Both platforms have slightly different hoops to jump through to enable test purchases, it's been awhile since I looked at it but I believe for android you have to upload a build to a testing channel before they become enabled.

Also you should probably have some error handlers as well, so you can see what's going wrong.

I had a quick look at the older admob plugin, for iOS it uses version 7.1.0 and for Android it uses whatever latest version is.

The C3 mobile-advert plugin uses 7.24.1 for iOS and 11.2.0 for Android. Note that AdMob doesn't have a unified versioning system between the iOS and Android version, so it's not that on iOS a really old version is being used.

Admob seem to be requesting 7.0.0 or higher for both which is a little confusing, but both plugins should fulfil this requirement. Either way I'm going to look into changing the mobile-advert plugin to use the latest version ( we're only a couple of months behind but it makes sense to keep up to date ).

It's considered a "hybrid app". Part of the application is "native"; like the webview wrapper and any native plugins your using (mobile advert for example). The rest of the code is "web", the game logic itself happens here and can trigger native code via the "cordova bridge".