I'm sort of imagining that what you're looking at is something that mines a (fixed? variable?) web-site's markup for information and then re-presenting it in the app's own chosen layout.
Do you have control of the source web-site(s), or are you taking third party information? If the former, then either you can ensure consistency of the code or provide in parallel a secondary, pared-down, web-page (perhaps a specific XML subset of the 'facts' being presented in (X)HTML form to the typical users), from which the details (the temperatures over the next few days, the last few trading prices, the contact names of those providing out-of-hours service, or whatever it is you're looking at pushing through the App.)
If the latter there's first of all possibly some concern about whether you are (morally or legally)
allowed to mine the information and then repackage it within the 'your brand' app. Like claiming to have up-to-date weather information but actually sourcing some other source's (licensed, if not self-compiled) forecast. And if that's not a problem (or you don't
consider it to be one) you are also at the whim of the source-site changing its formatting on you. Something I use to compile (for personal use!) radio broadcast information from the broadcasters' respective listing pages has to deal with that problem. Personally I create an "interpretation file", something that contains a sort of 'pseudocode' that I can define new ways to guide how the main program regexps out the vital information that I desire.
When it breaks (like when they went all <div> and <span> on me, a while a go, and then later when they changed the "class" ids of the various subsections) I find this out when I run the mining-program and then have to look to see what went wrong and edit (usually) the interpretation file or (very occasionally) also the mining program itself to add a mechanism to interpret a new pseudo-coded 'interpretation' function that I find I need.
From the end of your post you
do talk about modifying the web-site's code (source code? ...no, I think you mean markup), so I think you're only liable to the former instance. i.e. of mining your own controlled information layout... and moreover (at least at the surface) information you have legitimate cause to 'rip' from the standard site ready for use in the (differently out?) App.
I would suggest that if your current website administration method allows[1] that you now create an easily[2]-parsed side-page from which to grab the data you wish to transfer.
If you can't do it automatically, with what you have, then you could always resort to a manual compilation version. Re-written whenever it needs updating. Whether 'plaintext' or 'encrypted' as per hinted at in footnote-2.
(And now I realise that the
latest XKCD is a very apt thing to mention at this point.)
Of course, I could be answering the wrong question, here, but basically the answer is almost certainly "it's possible". Whether it's practical or
necessary I leave up to you and those who are trying to accomplish the technical aspects of this currently conceptual project, who actually know the whys and the wherefores involved...
[1] Maybe a
CMS that has a Single Source Of Truth feature in it, thus already updating multiple web-pages depending on some global setting... e.g. a table of opening hours for each store in a chain that gets displayed in a master table on one page or (of the appropriate subset only) on the page showing and comparing the nearest five stores to a location, and again (just for the appropriate store) on each and every store's own individually targetted information page.
[2] Easy for you and your app. You may wish to obfuscate it in some manner if you wish to protect yourself from 'hostle' data-miners so easily pinching your information in the same way. A simple cryptographic conversion of information with a rotating key that the App has the wherewithal to use to reconstruct the base information, perhaps. Public/Private-key might be necessary. (Especially if you wish to authenticate the info source, in case of someone man-in-the-middling.) But I don't know what data you're peddling so this is probably overkill.