App photos saving as AVIF format

Developer General
1

All of a sudden today the iOS app has started saving photos as AVIF.

Since I use JPG job photos in my companion app, this has broken a few things.

Does anyone know how to change it back to jpeg?

2

Hi Chris,

The latest version of the ServiceM8 app now saves photos in AVIF format. However, sharing photos via email, SMS, or other sharing methods will continue to use JPEG for compatibility.

Which companion app are you working with, and how are you transferring the photos to it?

Thanks,
Ava

3

Hi Ava.

I have a companion app for writing detailed termite inspection reports.

My app downloads between 20 and 100 photos for embedding in reports. My PDF generator can’t handle AVIF files; only JPGs

I’m glad there’s still JPG compatibility. Does that mean you guys store a separate JPG file on your end, or convert on the fly?

Is there a way for us devs to access the JPGs, either a stored version or access your JPG conversion endpoints?

Cheers.

4

Hi Chris,

There isn’t a customer-facing ServiceM8 setting we can point you to that forces photos taken through the ServiceM8 camera back to JPG/JPEG.

For a companion app/API workflow, the safer approach is to avoid hard-coding .jpg and read the Attachment record’s file_type field, since the Attachment API includes file_type on attachment records.

If the images are coming from the iPhone Camera Roll rather than being taken in ServiceM8, check iPhone Settings > Camera > Formats > Most Compatible for new JPEG photos.

If this is affecting photos taken directly in the ServiceM8 app and you need JPG/JPEG output for your account, email support@servicem8.com with a couple of affected job/photo examples so we can check it privately.

Thanks,
Cody

5

This caught me out too.

I have a couple of paid add-ons in the store that rely on reading photos. Didn’t realise this was the root cause of some reported user complaints until after-the-fact. Have since updated the codebase to deal with AVIF. But, had we been given an early warning before a change like this taking place it might have avoided complaints and negative feedback from disgruntled users, and given us time to perform code updates and regression testing.

Or, is there already early warnings for said changes and I missed them?

6

Hi Chris,

For API-based downloads, we’d treat the job photo as the attachment format returned by the Attachment API, rather than assuming a JPG will be available.

The documented Attachment API provides access to file attachments including photos, and attachment records include fields such as related_object_uuid, file_type, photo_width, and photo_height.

There isn’t a documented API parameter or developer endpoint for requesting a JPG rendition of an AVIF photo through the Attachment endpoints, and we can’t confirm a separate JPG file is available to developers via the API.

For your report app, the safest approach is to read file_type for each attachment and branch your logic for AVIF files before sending them to your PDF generator.

Thanks,
Cody

7

Hi Franco,

You didn’t miss a dedicated developer early-warning channel that we can point you to from Support at the moment.

The public resources we can point developers to are the ServiceM8 Developer Portal for API/add-on documentation and reference material, and the ServiceM8 Updates page for released feature updates.

For attachment/photo workflows, the Attachment API exposes file_type on attachment records, so integrations should treat the file type as data rather than assuming JPG/JPEG.

That’s fair feedback: changes that affect add-ons can create real support load for developers, and we’ll pass this on to the relevant team as feedback about clearer advance notice for integration-impacting changes.

Thanks,
Cody