On this page · 8 sections
Summary. The Connectivity Standards Alliance released Matter 1.5.1 on 31 March 2026, four months after Matter 1.5 landed on 20 November 2025 with camera, closure and TCP transport support. Apple's AccessorySetupKit, introduced in iOS 18, removes the Bluetooth permission prompt entirely for accessories declared in your Info.plist. Google Play requires new apps and updates to target Android 16, API level 36, from 31 August 2026. AWS IoT Core prices 24/7 connectivity at $0.042 per device per year in US East and meters messages in 5 KB increments at $1.00 per million. And the EU Cyber Resilience Act's reporting obligations bite on 11 September 2026, retroactively, on products already on the market. The phone app is rarely what delays a connected-device programme. The certification and pairing surface is.
That is the honest framing for anyone commissioning an IoT app: the client code is six to ten weeks of work, and the regulatory and platform gates around it are the schedule.
What the mobile layer actually has to do
An IoT mobile app has four jobs that a normal app does not: discover a device that has never been on a network, hand it credentials without exposing them, hold a control session that survives connectivity loss, and deliver firmware updates you can roll back. Each of those has been reshaped in the last eighteen months.
Matter is now a camera and closure protocol, not just a lightbulb protocol
The Connectivity Standards Alliance's Matter 1.5 release, 20 November 2025 added cameras, closures, soil sensors and energy tariffs. Cameras stream over WebRTC, and the release notes are specific: Matter cameras "support live video and audio streaming using established WebRTC technology" via standard STUN and TURN. The same release added full support for operation over TCP transport, which matters for anything moving payloads too large for the original UDP-oriented design.
Matter 1.5.1, released 31 March 2026, extended that with multi-stream video and audio, HEIC snapshots, HLS and DASH upload through the CMAF Interface-2, pan-tilt-zoom fixes and chime sound selection. As of 15 August 2026 there is nothing newer than 1.5.1 in the Alliance newsroom, so a build targeting 1.5.1 is targeting current.
Thread sits underneath for low-power mesh, and the current specification is Thread 1.4.1. Plenty of published integration guides still say 1.4, which is one revision behind.
Steve Kaufer, Director of Engineering, R&D for Lighting Controls at Legrand, put the commercial case for Matter plainly in a CSA interview published 12 August 2026: "Matter is providing ease of interoperability. It makes it very easy to bring products into an ecosystem and get interoperability between different manufacturers' products."
iOS pairing changed, and most apps have not caught up
Apple's AccessorySetupKit is the largest usability change in IoT app development in years, and it is widely under-used. In the WWDC 2024 session that introduced it, Apple states that "in iOS 18 and iPadOS 18, we created something to help you make the setup experience for your accessories even better", and that the framework "supports Bluetooth and Wi-Fi accessories."
The consequential line is this one: "Since we declared AccessorySetupKit support in our Info.plist, unlike previous versions of iOS, people will not be asked for permission to use Bluetooth." A pairing flow that previously showed a system Bluetooth permission alert, with the drop-off that implies, now shows a picker scoped to your own hardware. Apple adds that "only accessories paired with your app will be returned in the scan results", and "this one tap will allow access to both Bluetooth and Wi-Fi from your accessory, if it supports both."
For an installed base already paired the old way, Apple provides ASMigrationDisplayItem, passed to the picker call "to upgrade the existing accessories to be managed by AccessorySetupKit."
If you are not using AccessorySetupKit, you are still declaring `NSBluetoothAlwaysUsageDescription` and, for any local discovery, `NSLocalNetworkUsageDescription`, and you are eating both prompts.
Android's permission trap has a footnote that breaks beacons
On Android, targeting API 31 and above means BLUETOOTH_SCAN, BLUETOOTH_ADVERTISE and BLUETOOTH_CONNECT are runtime permissions surfaced to the user as "Nearby devices", per Android's Bluetooth permissions documentation, last updated 13 August 2026.
The standard advice is to add android:usesPermissionFlags="neverForLocation" to the BLUETOOTH_SCAN declaration so you can drop ACCESS_FINE_LOCATION. Google's own note on that page is the part teams miss: "If you include neverForLocation in your android:usesPermissionFlags, some BLE beacons are filtered from the scan results." If your product uses beacons for proximity or room-level presence, that flag silently breaks it.
The cleaner path for a single-purpose companion app is CompanionDeviceManager, available since Android 8.0. Google's documentation states the CDM "provides a pairing UI on behalf of your app and doesn't require location permissions." It is the Android analogue of AccessorySetupKit, and it has been available far longer than most IoT apps have used it.
One hard deadline sits on top of all of this: Google Play's target API requirements state that from 31 August 2026, new apps and app updates must target Android 16, API level 36, to be submitted, with extensions available to 1 November 2026. A connected-device app that cannot ship an update is a device you cannot patch.
| Pairing approach | Permission prompts shown | Scan scope | Availability |
|---|---|---|---|
| iOS AccessorySetupKit | None for Bluetooth | Only accessories paired with your app | iOS 18 and later |
| iOS CoreBluetooth direct | Bluetooth, plus local network if discovering | All nearby peripherals matching your filter | All supported iOS versions |
| Android CompanionDeviceManager | System pairing UI, no location permission | Devices matching your association filter | Android 8.0 and later |
| Android BLUETOOTH_SCAN with neverForLocation | Nearby devices | Filtered, some BLE beacons excluded | Android 12 and later |
| Android BLUETOOTH_SCAN with ACCESS_FINE_LOCATION | Nearby devices and location | Unfiltered, beacons visible | Android 12 and later |
The cloud bill, at published rates
Two platforms cover most of this market, and only one of them publishes prices that can be verified from the page.
AWS IoT Core pricing is explicit and worth reading as unit economics rather than a total. Connectivity is $0.08 per 1,000,000 connection-minutes, which AWS works through on the page as "$0.042 per device per year" for 24/7 connectivity in US East (N. Virginia). Messaging is $1.00 per 1,000,000 messages for the first billion per month, but the metering rule is what drives the invoice: "messages are metered in 5 KB increments", with a 128 KB maximum, so an 8 KB message bills as two. Device Shadow and registry operations are $1.25 per 1,000,000, metered in 1 KB increments. The rules engine charges $0.15 per million rules triggered plus $0.15 per million actions applied. For India deployments, AWS lists IoT Core endpoints in Asia Pacific (Mumbai), ap-south-1. Regional rates differ from the worked examples above, so price your own region rather than assuming parity.
Azure IoT Hub publishes its capacity model clearly even where the dollar figures are rendered dynamically. Microsoft's scaling documentation gives unit sizes of 400,000, 6,000,000 and 300,000,000 messages per day for tier sizes 1, 2 and 3, with up to 200 units for sizes 1 and 2 and 10 units for size 3. Basic tier omits cloud-to-device messaging, device twins, IoT Edge and Plug-and-Play, and you can upgrade Basic to Standard without interrupting operations but cannot downgrade. The billing granularity is the number to design around: Microsoft's pricing guidance states that "all billable operations are charged in 4K-byte blocks on basic and standard tier IoT hubs", and that twin reads, twin updates, direct methods and their responses each bill separately.
Both of those metering rules point the same way. Telemetry payload design is a cost decision. A device emitting a 6 KB JSON blob every thirty seconds costs twice what the same data costs at 4.9 KB on AWS, and a chatty device-twin pattern on Azure multiplies operations that look free in a diagram.
Underneath both, the transport is still MQTT Version 5.0, an OASIS Standard dated 07 March 2019. There is no 5.1 or 6.0. Anyone quoting a newer MQTT version is quoting a broker's product version, not the specification.
India: certification is the schedule risk
This is the section that turns a six-month plan into a ten-month plan, and it changed materially in 2025.
The legal basis for mandatory telecom equipment certification moved. The Telecommunications (Framework to Notify Standards, Conformity Assessment and Certification) Rules, 2025, G.S.R. 315(E), dated 16 May 2025%20Rules,%202025.pdf), were made under section 19 of the Telecommunications Act 2023 and expressly supersede rules 528 to 537 of the Indian Telegraph Rules, 1951. Rule 8(2) carries the prohibition: "No telecommunication equipment to which a standard applies, shall be sold or deployed in any telecommunication network, or otherwise be used in India, unless it has a valid Certificate of Conformity Assessment." Rule 12(2) sets the penalty at ten times the fees, and Rule 12(3) allows seizure or destruction of equipment.
The Telecommunication Engineering Centre's MTCTE pages list an Essential Requirement for IoT Gateway, and notification of Wi-Fi CPE and IP Router including security testing. Security certification runs as a separate track through the National Centre for Communication Security under the Communication Security Certification Scheme, with 78 Indian Telecom Security Assurance Requirements documents now notified on its download register, including generic groups of devices.
Radio approval is easier than it used to be. The Department of Telecommunications moved Equipment Type Approval for licence-exempt wireless devices to a self-declaration basis, per its office memorandum of 09 September 2024, granted through SARAL Sanchar, with radar, jammers, drones and satellite equipment excluded. ETA covers radio frequency only.
New in 2026, and barely covered: the Telecommunications (Radio Equipment Possession Authorisation) Rules, 2026, G.S.R. 592(E), dated 8 July 2026 require authorisation for anyone who manufactures, imports for sale, hires out, repairs, tests or demonstrates radio equipment, at Rs 10,000 per year for dealing and Rs 2,000 per year for test and demonstration, with the portal live from 06 August 2026. If your programme includes a test lab or a demo fleet, that is a new line item.
Product safety is separate again. BIS Compulsory Registration operates under the 2021 Order, most recently amended by S.O. 1246(E) dated 10 March 2026 with effect from 15 June 2026, per the gazette published by BIS, against IS/IEC 62368 Part 1: 2023. There is no generic "IoT" category in CRS; a device is caught only if it falls within a named category, which is a determination worth making early rather than at the border.
Data protection is a 2027 problem you build for now. The Digital Personal Data Protection Rules, 2025, notified 13 November 2025 and listed with their corrigendum on India Code, commence in three tranches: rules 1, 2 and 17 to 21 on publication, rule 4 one year later, and rules 3, 5 to 16, 22 and 23 eighteen months later. That puts Consent Manager registration at 13 November 2026 and the notice, consent, security-safeguard and breach-reporting duties at 13 May 2027. Rule 6 names the expected safeguards as encryption, obfuscation, masking or the use of virtual tokens, with logs retained one year. Rule 7 requires the data principal to be intimated of a breach without delay, and the Board within seventy-two hours in full detail. Device telemetry that identifies a household is personal data, and the retrofit is far more expensive than the design. We set out the wider engineering view in our DPDP Act engineering playbook for Indian startups.
Export markets: three regimes, three different clocks
If the device ships outside India, three more regimes apply, and only two of them are actually running.
The EU Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024. Chapter IV applies from 11 June 2026, reporting obligations from 11 September 2026, and the Regulation is fully applicable from 11 December 2027. The clause that changes hardware roadmaps is in the Commission's own summary: reporting obligations apply to products "including those already placed on the market before 11 December 2027." The reporting mechanics are an early warning within 24 hours, full notification within 72 hours, and a final report no later than 14 days after a corrective measure is available. The declared support period must be specified clearly at the time of purchase.
The UK's Product Security and Telecommunications Infrastructure regime came into force on 29 April 2024. The statutory instrument sets three requirements: passwords "must be unique per product; or defined by the user", at least one point of contact for security reports with acknowledgement and status updates, and a published defined support period which is "not met if the defined support period is shortened after the publication." The Statement of Compliance is retained for ten years. There is a trap in the drafting: the SI defines the standard as ETSI EN 303 645 V2.1.1 dated 19 June 2020, while the current published standard is V3.1.3, September 2024. Certifying to the current ETSI version does not by itself give you the UK deemed-compliance route.
The US Cyber Trust Mark is not a gate yet. The FCC's public notice DA 26-75 confirms conditional approval of Cybersecurity Label Administrator applications "will not allow CLAs to certify products to use the FCC IoT Label before obtaining accreditation", UL Solutions withdrew as Lead Administrator on 19 December 2025, and the ioXt Alliance was selected on 13 April 2026 to finalise implementation. The programme is not accepting product applications. Do not put it in a launch plan as a deliverable.
| Regime | Status as at 15 August 2026 | Key date | What it demands |
|---|---|---|---|
| EU Cyber Resilience Act | In force, phasing in | Reporting from 11 Sep 2026, full 11 Dec 2027 | 24h/72h/14-day vulnerability reporting, declared support period |
| UK PSTI | Fully in force | 29 April 2024 | Unique or user-set passwords, security contact, published support period |
| India MTCTE | In force under 2025 rules | G.S.R. 315(E), 16 May 2025 | Certificate of Conformity Assessment before sale or deployment |
| India WPC ETA | In force, self-declaration | OM of 9 Sep 2024 | Self-declared type approval via SARAL Sanchar |
| India DPDP Rules | Notified, phasing in | 13 Nov 2026 and 13 May 2027 | Consent architecture, safeguards, 72-hour breach reporting |
| US Cyber Trust Mark | Not launched | ioXt selected 13 Apr 2026 | No product applications accepted |
What we build, and how the engagement runs
For a connected-device programme, the mobile scope we deliver is:
- Provisioning and pairing. AccessorySetupKit on iOS with an
ASMigrationDisplayItempath for an existing installed base, CompanionDeviceManager on Android, and a credential handoff that never writes Wi-Fi secrets to logs or analytics.
- Control and state. A local-first control path over BLE or local network with cloud fallback, so the app still works when the broadband does not.
- Telemetry and cost design. Payload sizing against the 5 KB AWS and 4 KB Azure metering boundaries, with batching where latency allows.
- Firmware update delivery. Staged rollout with a rollback path and a support-period record that satisfies the UK PSTI and EU CRA publication duties.
- Consent and privacy. A purpose-keyed consent ledger and the Rule 6 safeguards, built before May 2027 rather than after.
Our delivery process runs as discovery and standards mapping, architecture and protocol selection, build in two-week increments with a working app pairing to real hardware from sprint two, hardening and security review under our ISO 27001:2022 practices, and launch with a defined support period documented. eCorpIT was founded in 2021, is headquartered in Gurugram, and holds CMMI Level 5, MSME certification and ISO 27001:2022, with partner relationships including AWS, Microsoft and Google. For every other framework named above, including the CRA, PSTI and DPDP, we design applications aligned with their requirements; we do not claim certification against them.
On engagement, we run a fixed-scope build where the hardware specification is frozen, a dedicated senior-led team on a monthly retainer where firmware and app are still co-evolving, which is the usual case in connected hardware, and a milestone-based build-and-transfer where you intend to take the codebase in-house. Connected-device work is co-evolving more often than not, and we will say so rather than sell you a fixed price that will need renegotiating in month three.
Related reading: our field view of smart manufacturing, IoT and AI in Indian factories covers the industrial end of the same stack, and on-device versus cloud AI in mobile apps covers where inference should sit when devices generate more data than you want to ship. If you are choosing a delivery model, our mobile app development RFP template and our comparison of agency versus freelancer for mobile app builds are the practical starting points. For teams weighing client technology, a hybrid app development company engagement can work for IoT, with the caveat that native modules still carry the pairing layer.
FAQ
How eCorpIT can help
eCorpIT builds the mobile and cloud layer for connected-device programmes, from provisioning and pairing through telemetry cost design to firmware delivery and the support-period record your export markets now require. We are a Gurugram-based company founded in 2021 with CMMI Level 5, MSME certification and ISO 27001:2022, working with AWS, Microsoft and Google as platform partners. If you are early enough that the protocol and certification path are still open, that is the point at which we add the most value, because those two decisions set most of the schedule. Tell us what you are building at contact us.
References
- Telecommunications (Framework to Notify Standards, Conformity Assessment and Certification) Rules, 2025, G.S.R. 315(E)%20Rules,%202025.pdf)
Last updated: 15 August 2026.
