Hi In my opinion experimenting with PD and delivering "some foley sounds and sound design" for a mobile app are two separate things entirely. Client deliverables and PD aren't really part of the same stream. They can be parallel thought read below ..
PD isn't a common way to hook sounds into a game. I've never hear of anyone using PD within the context of a basic mobile app and its really VERY rare for PD to be used at runtime for commercial games. Obviously there are a few exceptions. You don't need to learn PD or programming to work on sound for games.
What you do need to know is how to communicate and understand the client expectations regarding how sounds would work within the context of the game so you can clearly define what A) you need to deliver and B) what the programmers need to do to get it working as intended.
The most common way for sounds to get hooked into a game is by a programmer simply calling sounds in a VERY basic manner IE : when "x" happens play sounds OR play sound looped then stop loop once "X" happens. Advanced audio features and middleware are not common in games until you get to large scale game development for PC and console. Most small developers particularly mobile developers are writing their own game engines anyway and they certainly won't have more than the most basic audio features.
If you took the time to learn PD (months) you could build demo's to show clients and programmers how the audio interactivity could work. This helps communicate ideas faster and gives everyone the chance to give feedback on sounds as they might work in game. I wish I had a quick audio prototyping tool like PD it would solve a lot of problems early on in pre-production.