Wow. That explanation confirmed my suspicions that the app designers for this game have no experience designing apps. A WELL WRITTEN app would not have that problem. In fact, it would not be necessary to release a new version every time a new tower came out.
To put it simply, a tower should be defined as a class. The class should inherit certain cannonical properties (e.g. health, attack power, super attack power, range, rate of fire, graphics resource identifier, etc) dynamically at load time. The properties should be stored in a database which is queried by the client at the time the data is actually needed (e.g. when a battle starts). That way when max tower level is increased from 60 to 65 (inevitable), the game would merely fetch a new row from the database. No change to the code or behavior of the game would be required to implement this.
Dragons would be constructed in a similar manner. The prototype dragon would inherit health, attack power, a spell word, and graphical resource identifiers.
Adding a new spells and special abilities is a little trickier, since it would be impossible to write a prototype spell class that could encompass all current and future spells and abilities. However this type of problem is routinely solved by using dynamic code libraries. The library would contain routines for each spell and ability with the code to handle that type of specific event, such as the casting of a fireball spell. When that fireball spell event occurs, the runtime engine would pass control to the fireball event handler which would draw the necessary artwork and calculate the damage dealt and then return control back to the runtime engine.
These are not complicated problems to solve. This is well established programming practice. This is the kind of thing you get when you hire a real programmer instead of someone who went to one of those 90 day coding boot camps and got a certificate. Well, this and also apps that don’t crash every 10 minutes…just saying.