Private corporate batches, live online cohorts and 1-on-1 mentoring in building, releasing, testing and securing Android and iOS applications — signing, pipelines, device testing and mobile app security — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
This programme is taught as mobile delivery and mobile security together, because the same team owns both. It covers the Android and iOS platform security architectures — sandboxing, code signing, the secure boot chain, Keychain and Keystore, data protection classes — alongside the release machinery that teams actually get wrong: keystores and provisioning profiles, automated signing, versioning, TestFlight and Play Console tracks, staged rollout and crash-rate gates. The security labs are run the way an assessment is run, with a proxy intercepting traffic, a decompiler open on the team's own release build, and runtime instrumentation defeating a client-side check live.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Mobile Engineering that means a trainer who has run it in production — building, releasing, testing and securing Android and iOS applications — signing, pipelines, device testing and mobile app security — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Mobile Engineering batchMobile engineering is the discipline of building, shipping and defending applications that run on someone else's device, on a network you do not control, behind a store review you cannot bypass. That last constraint is what makes it different from web engineering. You cannot patch a bad release in five minutes; a broken build reaches users through a staged rollout you have to halt, and older versions of your app keep talking to your API for months afterwards.
The platform layer is Android and iOS. On Android the work is Kotlin against the Android SDK, activities and lifecycle, Gradle builds, keystores and Play Console release tracks, plus a permission and sandbox model enforced by the kernel. On iOS it is Swift against UIKit or SwiftUI, Xcode build settings, provisioning profiles and certificates, App Store Connect and TestFlight, plus a security architecture built on the secure boot chain, code signing, application sandboxing, the Keychain and hardware-backed data protection. Cross-platform stacks — React Native, Flutter, Kotlin Multiplatform — sit above these and remove some duplication, but every one of them still lands on the same signing, distribution and store-review reality underneath.
Around the platforms sit two bodies of practice that decide whether a mobile team is fast or slow. Delivery: reproducible builds, managed signing identities, automated versioning, test execution on real devices, and staged rollouts with crash-rate gates. And security: an attacker holds the device, so the client binary, its local storage and its network traffic are all inspectable. Certificate pinning, secure storage, obfuscation, root and jailbreak detection, and testing your own app the way an attacker would — with a proxy, a decompiler and a runtime instrumentation tool — are ordinary engineering tasks in mobile, not specialist extras.
Mobile is where most consumer transactions and a growing share of internal enterprise workflows now happen, and the applications carry authentication tokens, payment credentials and personal data on hardware the organisation does not own. Regulators and payment schemes have noticed: mobile applications are increasingly in scope for the same assessment that back-end systems have had for years.
At the same time delivery expectations have risen. Teams are asked to release weekly, on two platforms, through two review processes, with staged rollouts and crash-rate gates — and most of them are still signing builds on someone's laptop with a keystore stored in a shared drive. The failure modes are predictable and expensive: a lost signing key that makes an Android app impossible to update, an expired provisioning profile discovered on release day, a regression that reaches ten per cent of users before anyone reads the crash dashboard.
The security gap is wider still. Most teams have never run their own application through a proxy to see what it sends, decompiled their own release build to see what a reverse engineer sees, or checked what ends up in local databases and preference files. Those are teachable, repeatable exercises, and doing them once changes how a team writes mobile code permanently.
The decisions made before any code, and what each one costs later. Native versus cross-platform versus mobile web, the store review and distribution model each implies, device and OS version fragmentation, and the offline, battery and network constraints that make mobile engineering different from web.
Topics: Android and iOS as engineering platforms, not just markets · Native, cross-platform and mobile web: honest trade-offs · React Native, Flutter and Kotlin Multiplatform in practice · Store review, distribution and enterprise sideloading · OS version fragmentation and minimum supported versions · Offline-first, connectivity and battery constraints · Backend-for-frontend and API versioning for long-lived clients · Analytics, consent and platform privacy requirements
Enough Android to build, debug and reason about an application's structure. Components and lifecycle, the manifest and permission model, the Gradle build system, and the developer tooling — adb above all — that every later delivery and security module depends on.
Topics: Application components: activities, services, broadcast receivers, content providers · The lifecycle and the bugs it causes · The manifest, intents and exported components · Runtime permissions and the permission model · The Gradle build: variants, flavours, build types, minification · adb: devices, logcat, shell, install, pull and push · Emulators and managed test devices · App storage: internal, external, shared preferences, SQLite and Room
The equivalent ground on iOS, where the platform is more prescriptive. Xcode project structure and build settings, the application lifecycle, and Apple's layered security architecture — secure boot chain, code signing, trusted application loading, sandboxing, data protection and Keychain.
Topics: Xcode projects, targets, schemes and build settings · UIKit and SwiftUI application structure and lifecycle · The secure boot chain and hardware root of trust · Code signing and loading only trusted applications · Application sandboxing and inter-app isolation · Data protection classes and file-level encryption · Keychain services and the Secure Enclave · Network security defaults and App Transport Security · Entitlements, capabilities and provisioning
The module that removes the release-day panic. Managing signing identities so no human holds a keystore, automated versioning, building on CI for both platforms, and driving TestFlight and Play Console tracks from a pipeline rather than a browser tab.
Topics: Android keystores, key rotation and Play App Signing · iOS certificates, provisioning profiles and automatic signing · Storing signing material safely and rotating it · Fastlane lanes for build, sign, upload and metadata · Gradle and xcodebuild in a CI environment · Automated versioning and build numbering · macOS build capacity: hosted runners versus self-hosted · Internal, alpha, beta and production tracks; TestFlight groups · Build reproducibility and artifact retention
Getting real confidence on hardware you do not control. Unit and instrumentation tests, UI automation with the platform frameworks and with Appium for cross-platform suites, running on real device farms, and the flakiness management without which nobody trusts the suite.
Topics: Unit tests and test doubles in mobile codebases · Instrumentation tests: Espresso and XCUITest · Appium for cross-platform UI automation · Screenshot and snapshot testing · Device farms and real-device coverage strategy · Test data, environment selection and network stubbing · Flaky test detection, quarantine and repair · Performance testing: cold start, jank, memory and battery · Accessibility testing on both platforms
What an attacker holding the device can actually do, and what the platform still guarantees. Threat modelling a mobile application against a recognised standard, then the defensive controls: secure storage, transport security and pinning, authentication and token handling, and the honest limits of client-side protection.
Topics: The mobile threat model: attacker with physical device access · MASVS and MASTG as an assessment framework · Secure local storage: Keystore, Keychain, and what not to store at all · Transport security, TLS validation and certificate pinning · Token handling, refresh, revocation and biometric re-authentication · Deep links, intent handling and inter-app attack surface · WebView risks and safe configuration · Third-party SDKs, telemetry and data leakage · Obfuscation, anti-tamper, root and jailbreak detection — and their limits · Why client-side controls delay rather than prevent
Running the assessment yourself, on your own application. Building a test environment with rooted and jailbroken devices or emulators, intercepting traffic through a proxy, decompiling and reading a release build, inspecting local storage, and using runtime instrumentation to defeat a client-side check live.
Topics: Building a test environment: emulators, Genymotion, rooted and jailbroken devices · Proxy interception with Burp Suite or mitmproxy, including certificate installation · Defeating and then hardening certificate pinning · Static analysis: apktool, jadx, class-dump and automated scanners · Inspecting local storage: SQLite databases, shared preferences and plist files · Runtime instrumentation with Frida and objection · Decrypting and unpacking store-delivered binaries for analysis · Debugger attachment and native code inspection · Reporting findings so developers can act on them · Feeding mobile scanning into a CI pipeline
Life after upload. Staged rollout with real gates, crash and ANR monitoring, remote configuration and feature flags for the changes you cannot ship instantly, forced-update strategy, and the store compliance work — privacy declarations, permissions justification — that blocks releases when it is left to the end.
Topics: Staged rollout, halt criteria and rollback options per platform · Crash and ANR monitoring, symbolication and triage · Performance and startup monitoring in production · Feature flags and remote configuration as a release safety net · Forced and recommended update strategies · Supporting old client versions and API deprecation · Store listing, privacy declarations and permission justification · Beta programmes and structured user feedback · Release metrics: adoption, crash-free rate, time to fix
We rebuild the agenda around the tools you actually run.
Request a custom agendaMove Android and iOS signing material into managed storage, then produce a signed build from CI that nobody could produce by hand.
Automate versioning, build, sign and upload so a tagged commit reaches an internal test track and TestFlight with no manual step.
Write UI tests for a critical flow, run them on real devices in CI, then diagnose and repair a flaky test instead of retrying it.
Proxy your own application, install a trust anchor, capture every request, then implement pinning and defeat it with runtime instrumentation.
Decompile your own release build, inspect the local data directory, and find at least one secret, endpoint or client-side check that should not be exposed.
Run a staged rollout with defined halt criteria, monitor crash-free rate and adoption, then stop the rollout on evidence and execute the recovery path.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.